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

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.

Comment on Re^5: Runtime introspection: What good is it?

Replies are listed 'Best First'.
Re^6: Runtime introspection: What good is it? by BrowserUk (Patriarch) on Jul 08, 2008 at 21:49 UTC
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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]

Replies are listed 'Best First'.

Re^6: Runtime introspection: What good is it?
by BrowserUk (Patriarch) on Jul 08, 2008 at 21:49 UTC

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

[reply]