Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

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

by stvn (Monsignor)
on Jul 06, 2008 at 20:40 UTC ( [id://695869]=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?

It should be noted that this code:

$o->method( ... );
requires runtime introspection to work.

Perl does not determine the method being called at compile time, instead it will lookup in the @ISA in a depth-first search to find the package which has a method of the name "method". The -> is an operator, that operator is a function just like any other function either built-in or defined by you. By calling the code of that operator you are explicitly telling Perl to do some runtime introspection to find and execute a method for you. So, hmm, I think maybe that saying:

Viola. No introspection needed.
is not quite correct.

-stvn

Replies are listed 'Best First'.
Re^4: Runtime introspection: What good is it?
by BrowserUk (Patriarch) on Jul 06, 2008 at 21:05 UTC

    Perl is interpreted. If you choose not to see the big distinction between those operations that are required for the operation of the language, and those (like UNIVERSAL::ISA and UNIVERSAL::can), that are not, then you're conducting an entirely different discussion to the one I set out to have.

    If you blessed (or tied) all your hashes, arrays and scalars, and provided clone() methods in each of those packages, then no introspection (in the sense of application programmer explicitly coded type-based dispatching), is required.

    Before you counter argue further, please think about why I might have asked the question I asked. Think about which side of this argument I might normally hang my hat. And think about why I might have phrased the premise in the way I did.

    It's unfortunate that you taken the stance you have because it means that I will now not get the responses I had hoped for. Ie. Real examples of how people are using explicit, programmmer driven, class-based introspection, in Perl. Ie. The very sort of stuff that Moose provides for. Ie. The very use cases that make the case for using Moose in the first place.


    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.
      Before you counter argue further, please think about why I might have asked the question I asked. ...

      Yes, none of this was lost on me, however I think your approach to the question is totally wrong. The issue is simply not a simple compile-time vs. runtime thing, it is much more subtle then that.

      Take a moment too and think about how long I may have spent pondering these exact issues, and how much time I have spend studying this problem (hint: it goes all the way back to my involvement in the Pugs project about 3 years ago). Pushing things down to compile-time does not make the complexity go away, nor does it make everything fast, it simply pushes the problem over to the other side of toolchain. In some cases, doing this can actually make the user level code more complex since you must make some decisions early, decisions that if you could wait until runtime would be much easier to make.

      It's unfortunate that you taken the stance you have because it means that I will now not get the responses I had hoped for. Ie. Real examples of how people are using explicit, programmmer driven, class-based introspection, in Perl. Ie. The very sort of stuff that Moose provides for.

      Honestly I think you should rephrase your question, because you were not asking for "how people are using explicit, programmmer driven, class-based introspection", but you were asking people to provide counter arguments to the premise that "There's nothing that can be done with run-time introspection that cannot be done (better) by compile-time decision taking", which is an entirely different thing.

      FWIW, most of what Moose does is quite possible to be pushed into compile-time (the class building stuff) and we are actually working on trying to make that happen, it is not nearly as easy as you might think. But that is only half of Moose, the other half is the introspection features that Moose provides, the ability to introspect all those things that were set up during "compile" time.

      The very use cases that make the case for using Moose in the first place.

      Here is where I think you are very wrong, the MOP and heavy runtime introspection is not the use case for Moose. The use case for Moose is that it provides a consistent means of writing Perl OOP. To remove the tedium of writing accessors, to formalize the idea of instance slots/attributes, to provide a sane and consistent environment for inheritance and to bring some sanity to the over-grown TIMTOWTDI that is the current state of Perl OOP. The fact that Moose also provides a full fledged MOP which can be used for clean introspection, reflection and manipulation of objects/classes is actually just a side effect of those other things. I needed to create the MOP in order to provide those other features.

      To be perfectly honest, I hardly ever reach for the MOP. It is very rare that I explicitly use it outside of the Moose core or a MooseX:: module. In fact, I even try to discourage people on #moose who seem to be using the MOP for the MOPs sake, especially when the non-MOP solution would be much simpler (maybe less exciting, but simpler).

      -stvn

        The fact that Moose also provides a full fledged MOP which can be used for clean introspection, reflection and manipulation of objects/classes is actually just a side effect of those other things. I needed to create the MOP in order to provide those other features.

        The distinction between MOP and Moose will obviously be very clear to you. You use the phrase "a full fledged MOP" with an alacrity that pre-supposes that I will know what a "MOP" is in this context.

        So you see, if the question was naively worded, it's perhaps because I am naive on this subject. I did expect the clone argument to come up, along with the IV/UV/NV/PV case--the JIT took me by surprise--but I didn't want to respond to those "special cases", until I'd received a few replies detailing the kind of use-cases that I think are questionable. (As opposed to those, like extending Perl's closed, built-in classes for which it is the only mechanism available.) I tried to defer my response to you, but you just kept popping up everywhere.

        The use cases I was expecting (hoping for; now dashed), fall into--that is, I currently, tentatively and perhaps naively, categorise into--two main categories:

        • Systems programmer use cases.

          These would include the internals of both Moose and by implication from what you've said, MOP. (Whatever that is.)

          And plug-in architectures.

          And, perhaps, object-relation mappers.

        • Application programmer use cases.

          These are the ones I'm most intrigued by.

          If you read about Ruby, RoR, Objective-C et al., then you could be forgiven for believing that reflection is both a desirable, and necessary part of any modern application programmer's lexicon. And by implication, any modern application programming language.

          It is here that I feel that there are questions to be asked, and hype to be countered. And from what you say:

          In fact, I even try to discourage people on #moose who seem to be using the MOP for the MOPs sake, especially when the non-MOP solution would be much simpler (maybe less exciting, but simpler).

          It seems that you might agree with me. Which is what I hoped for, even expected, when I first saw you respond to my post. Who better to get on side in support of my premise. Hence my desire to defer our discussion until I had garnered some alternate views to discuss.

        Even the 'systems programmer use cases' can, in many, if not all instances, be achieved with compile-time decision taking and/or code generation. Again, from your statement:

        FWIW, most of what Moose does is quite possible to be pushed into compile-time (the class building stuff) and we are actually working on trying to make that happen, ...

        I would seem that you agree with this also. The question here becomes: Is is better to do so? (Hence the parens in "... be done (better) by compile-time decision taking". As you say, "it is not nearly as easy as you might think." and "In some cases, doing this can actually make the user level code more complex...".

        And that identifies the kind of area of my naivity that I wish to improve. Where do the break points come?

        Honestly I think you should rephrase your question,...

        Perhaps you're right. Maybe I should start a new thread with a more carefully specified premise and try again. The problem with trying to do that the first time around was that I didn't (still don't) know exactly what my conclusions are going to be. So, the more targetted I make the question, the more likely I am to pre-bias it to a particular type of response. But, with the hindsight of this thread, maybe that would not be such a bad thing.


        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://695869]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (5)
As of 2024-03-29 14:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found