We don't bite newbies here... much | |
PerlMonks |
Re^5: Runtime introspection: What good is it?by stvn (Monsignor) |
on Jul 07, 2008 at 02:55 UTC ( [id://695902]=note: print w/replies, xml ) | Need Help?? |
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
In Section
Meditations
|
|