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.

The distinction between MOP and Moose will obviously be very clear to you. You use the phrase "a full fledged MOP" with an alacrity that pre-supposes that I will know what a "MOP" is in this context.

So you see, if the question was naively worded, it's perhaps because I am naive on this subject. I did expect the clone argument to come up, along with the IV/UV/NV/PV case--the JIT took me by surprise--but I didn't want to respond to those "special cases", until I'd received a few replies detailing the kind of use-cases that I think are questionable. (As opposed to those, like extending Perl's closed, built-in classes for which it is the only mechanism available.) I tried to defer my response to you, but you just kept popping up everywhere.

The use cases I was expecting (hoping for; now dashed), fall into--that is, I currently, tentatively and perhaps naively, categorise into--two main categories:

• Systems programmer use cases.

  These would include the internals of both Moose and by implication from what you've said, MOP. (Whatever that is.)

  And plug-in architectures.

  And, perhaps, object-relation mappers.

• Application programmer use cases.

  These are the ones I'm most intrigued by.

  If you read about Ruby, RoR, Objective-C et al., then you could be forgiven for believing that reflection is both a desirable, and necessary part of any modern application programmer's lexicon. And by implication, any modern application programming language.

  It is here that I feel that there are questions to be asked, and hype to be countered. And from what you say:

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

  It seems that you might agree with me. Which is what I hoped for, even expected, when I first saw you respond to my post. Who better to get on side in support of my premise. Hence my desire to defer our discussion until I had garnered some alternate views to discuss.

Even the 'systems programmer use cases' can, in many, if not all instances, be achieved with compile-time decision taking and/or code generation. Again, from your statement:

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

I would seem that you agree with this also. The question here becomes: Is is better to do so? (Hence the parens in "... be done (better) by compile-time decision taking". As you say, "it is not nearly as easy as you might think." and "In some cases, doing this can actually make the user level code more complex...".

And that identifies the kind of area of my naivity that I wish to improve. Where do the break points come?

Honestly I think you should rephrase your question,...

Perhaps you're right. Maybe I should start a new thread with a more carefully specified premise and try again. The problem with trying to do that the first time around was that I didn't (still don't) know exactly what my conclusions are going to be. So, the more targetted I make the question, the more likely I am to pre-bias it to a particular type of response. But, with the hindsight of this thread, maybe that would not be such a bad thing.