http://qs1969.pair.com?node_id=696234


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

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.

Replies are listed 'Best First'.
Re^4: Runtime introspection: What good is it?
by BrowserUk (Patriarch) on Jul 08, 2008 at 16:16 UTC
    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.
      Doesn't that just push the reflection out to the class builder? It's no longer run-time for the application using the generated ORM, but the generator still benefits from reflection in its run-time. Or am I missing the point?

      Incidentally, I have used Class::DBI::Loader in the past to generate the ORM classes once, and then used the resulting in-memory model to write out static .pm files. I think that's both an illustration of your off-line class generator, but also of how CDBI::Loader benefits from reflection to build its model -- if it does, in fact. I can't vouch for that, to be honest, because I haven't looked at that module in ages. It certainly seems like it would in my mind.

        Doesn't that just push the reflection out to the class builder?

        No. Or at least, not necessarily.

        I wrote a (primitive) 'ORM' using C and Embedded SQL against DB2 15 or more years ago. The objects were simply c-structs constructed from table schemas queried from system tables. Assessors were simply functions addresses through a dispatch table. The constructors queried the table, performed any necessary data conversions on the fields before allocating a struct and populating it. Each 'class' is written out as a C-source and compiled to an object library against which application were statically linked.

        About the only thing that could even vaguely be termed "run-time refletion" was a binary hack to bypass a hardcoded, statically allocated limitation on the number of cursors available. Part of the C compile-time generated Embedded SQL. And that amounted to simply patching an address in a library generated struct to bypass the statically allocated cursor table to an enlarged one allocated at run-time. Until such times as the stick-in-the-muds on the DB2 development team wrapped their heads around the idea of dynamic memory allocation.

        There was no reflection involved in either the generator, the 'classes' or the user applications. Though I suppose you could term querying the system tables for schemas, a form of reflection, but it's a bit of a stretch.

        but also of how CDBI::Loader benefits from reflection to build its model -- if it does, in fact.

        From a brief foray into the CDBI::Loader::Generic source, it appears to eval the generated classes into existance. And that's where the flexibility (or fuzziness if you prefer) of what consititutes 'compile-time' in Perl arises. The code is generated at run-time for the CDBI::L::G. But it is evaled into a different package space, so there is no self-modification aspect going on. And the resulting classes are just bog-standard Perl that could be generated to a file once (per schema change) and the loaded in the normal way.

        Whether you can consider that 'run-time reflection' depends upon your goals I suppose. In keeping with my goal of supporting my premise, I going to say no :)


        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.