http://www.perlmonks.org?node_id=696075


in reply to Runtime introspection: What good is it?

I've been producing and consuming YAML lately. If you have objects serialized to text, you need some form of introspection to reconstruct them with a generic parser. The YAML parser does not know or care about the code in those other modules. It just assumes that the names in the input correspond to classes currently loaded by whomever called the parser. It relies on the language's introspection system to convert the strings in the YAML into calls to constructors.

I'd be happy to hear of a generic parsing method for this type of introspection, as it could make my code more efficient. But I think giving up introspection would require giving up genericity.

Phil

The Gantry Web Framework Book is now available.

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

    First. Thanks for being the first to post a real application.

    I going to assume that what you are doing is passing the blessed handles to live (populated) instance of hash(or array)-based objects to yaml, and having it return a string that contains:

    1. The name of the class;
    2. The attribute name/current value pairs of the instance.

    In essence, exactly the same as passing a hash to Data::Dumper, Data::Dump, Data::Dumper::Serial.

    This is a convenient side-effect of using Perl's hashes as the basis of OO. And it's not something that I would want to give up. Indeed, it's one of two primary reasons for my eshewing InsideOut implementations. Forcing the user to hack the source on those rare occasions when it it necessary to look inside an object simply are not worth the loss of convenience, all the extra work or the abysmal performance.

    But, it is only a convenience. It is perfectly possible to serialise (say) an inside-out object, or as I used once for a application that needed millions of instances and I needed to save space, a blessd scalar containing a packed string of the instance data. You simply have to provide a toString() and fromString(), or STORABLE_freeze() STORABLE_thaw() methods in each of your classes. Extra work, but perfectly doable.

    With things like Moose and Class::Std (if your that way inclined), or many of the other OO frameworks, these can (or could) even be generated for you from the Class definition.

    So, whilst convenient, useful and very usable, this use case doesn't contradict my premise.


    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.
      I left out one detail -- sort of on purpose, for which I apologize. My recent work was in Java where I needed the reflection package to have a hope of completing the task. Our goal is to be able to generate and use the YAML data in java for day to day work while turning to perl to handle disasters in our clients.

      My definition of introspection or reflection, which I take as synonyms, is anything a Java programmer would need the reflection package for. Perl provides many different syntactic ways to reach the same effects, I call all of those reflection. Thus, in my book, using a string to bless an object into someone else's class is reflection.

      The most popular reflection users these days are then Object Relational Mappers (ORMs). They need to manufacture classes at run time, for this they need the language's reflection system.

      Phil

      The Gantry Web Framework Book is now available.
        The most popular reflection users these days are then Object Relational Mappers (ORMs). They need to manufacture classes at run time, for this they need the language's reflection system.

        Yes. I picked out ORMs (along with Plug-in architectures and frameworks) as "system programmer use cases" in Re: i want to learn programming language. I definitely see the case for these uses of run-time reflection in (potentially) simplifying and clarifying the code required to achieve them.

        However, I believe even these can be achieved through compile-time code generation. In the case of ORMs, if you query the schema of the tables to be mapped, these are defined in terms of a limited set of datatypes. Ie. the particular RDBMSs own native type set. It therefore becomes possible to construct a base library of mappings between that set of datatypes and those of the host language. Then, at compile time, you can query the schema of the tables and build a class that maps the fields of the table to attributes with accessors that do whatever translation is required between the two sets of datatypes.

        In this way, you end up with a wholy generated, concrete custom class (alliteration unintentional), for each table. This can be done relatively easily in static or dynamic languages. (Even Java! :)

        And of course, given sufficient information available from the schema, it can even handle cross table dependancies (foreign key constraints etc.) far more easily and efficiently than using run-time reflection. It is quite easy to see how you can perform the 'schema to class generation process' offline, once-only when the schema changes, rather than everytime at run-time, whether it has changed or not.

        In the archetypal scenario for ORM use, that of servers fielding high speed, connectionless protocols, this removal of run-time effort by pre-compiling can become very critical. Of course, dynamic languages tend to benefit less from pre-compilation than statics, but even they can benefit hugely.

        Pre-loading a suite of pre-generated class definitions at mod_perl/Fastcgi "load time" and then just using them, is far better than having to generate the mappings, reflection-wise on-the-fly, for every page load.


        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.