Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re^3: Runtime introspection: What good is it?

by tilly (Archbishop)
on Jul 12, 2008 at 15:35 UTC ( [id://697243]=note: print w/replies, xml ) Need Help??


in reply to Re^2: Runtime introspection: What good is it?
in thread Runtime introspection: What good is it?

I'm going to reject your rejection of JIT on the basis of the fact that there are things you can do with JIT that you simply cannot do at compile time. And furthermore while it is true that what changing what JIT does is beyond the control of the programmer, deliberately taking advantage of its full capabilities is not.

A runtime type check followed by a runtime branching operation is exactly the kind of code that JIT can optimize away if you have a good JIT system.

However I reiterate that JIT is a red herring in the case of languages like Perl that don't have it.

Going to your exception solution, that solution has a major drawback. There are lots of possible reasons why there could be an exception, and your code has swallowed most of them. Easily fixable, granted, but not without adding more code and obscuring what is going on. And it is easy for a programmer to forget that they need to do that - I've seen many forget exactly that, including you just now.

Not to mention the fact that if Perl made a minor change to its error message, then your code would break. Not that Perl is likely to do that, but they haven't promised they won't, and they have documented how UNIVERSAL::can works.

Furthermore your criticisms strike me as unrealistic. If I define a plugin API, I expect to have things passed into it that are designed to be plugins. Yes, it is possible (but unlikely if you use descriptive method names, which I try to) that some random module might implement methods named the same as what I expect in my plugins. But if so then it still doesn't matter because no sane programmer is going to be passing it into my module as a plugin. (I can't solve the problem of insane programmers, and I refuse to try.)

Thus trying to use something that isn't a plugin as a plugin is not a problem that I'm going to waste code protecting against.

Now we have the problem of dealing with a badly designed plugin that doesn't do what it is supposed to do. Before you even consider doing that, you need to understand your problem domain. My problem domain is that I am writing plugins for use in my own module. If the plugin doesn't do what it is supposed to, that is a bug that I will fix. There is, therefore, no need for me to protect against that case. The same would apply for many of us.

A problem domain that more closely mirrors what you're saying is one where you're writing a popular application which random third parties will add plugins to. But even there you can defend the position that it is the responsibility of the plugin author to make sure they follow your API, and not yours to code against the possibility that they didn't.

Replies are listed 'Best First'.
Re^4: Runtime introspection: What good is it?
by BrowserUk (Patriarch) on Jul 12, 2008 at 17:13 UTC
      How is it cavalier to be extremely clear on who is responsible for what in your code? When you code in one place is trying to second guess code in another that it can't control, that just leads to mess and no safety. That mess can cause confusion and real errors (such as the improper ignoring and swallowing of error messages in your code snippet).

      My opinion is if you have a plugin system you have two sane options. The first is to trust that the plugin is coded properly. That will be the best option within most corporate code bases. The second is to build an explicit controlled security environment (eg a sandbox) and make sure the plugin in that environment. That is a lot of work and adds a lot of complexity but is sometimes necessary. However if you go that route, don't do it halfway.

        When you load file names from a (corporate) config file, you can reasonably expect that they will exist and have the right permissions, but I'd still never omit the error checking on the open.

        Even if your plug-in is written 'to spec', it can still cause exceptions, whether through coding error or coding design. Protecting your framework from errant plug-ins is such a simple step to take, it doesn't make sense not to.

        Methinks you're arguing the man, not the issue.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://697243]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others contemplating the Monastery: (5)
As of 2024-03-28 08:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found