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 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.

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

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.