I am quite biased here as I am a Lisp fan, but for me the state of the art continues to be mostly, the three decades old idea of having a metaobject protocol or an equivalent mechanism, allowing the programmer to redefine how objects behave (method resolution and composition and even maybe dispatching, storage, dynamic class creation, etc.).

Adding support for a proper MOP would require breaking backward compatibility for XS. If I recall it correctly, that was the main pain point found by Stevan Little when he tried to do it (or well, it has been a long time, so maybe that was my conclusion when I tried to imagine how to do it and I am now confused and attributing my thoughts to Stevan). In any case, my point was that if Perl 7 was going to break backward compatibility, then why not take advantage of the situation to also change the internals for something so important (in my opinion) as having a powerful and future proof OO system?

It seems that the idea of releasing a backward incompatible Perl 7 has now been reconsidered and so my point has become mot!

I also have to say that now, that you have forced me to review the Cor proposal with more attention, I see no reason why a MOP (or equivalent) couldn't be added in the future. So far, I can not find any place where you are closing doors, I find the syntax pretty flexible and consistent so, I am all in for Cor!

... and I was going to finish my message here, but you have asked me for solid examples, and so far I have just make vague request for a MOP, without really justifying what I thing we need one, so let me show an example of something solid: Class::StateMachine

That class is actually a metaclass. It uses the MRO hooks to redefine object resolution so that method dispatching takes into account the object class but also its current internal state. As an example, if you have a class Dog modeling a dog, with a on_head_touched method, you can declare several implementations for that method in such a way that the behavior when the dog is happy or angry is different.

Then there is Class::StateMachine::Declarative that exposes the functionality from C::SM in a more friendly and feature rich fashion though, still ugly because everything has to fit into a Perl data structure. The important thing here, is not that those modules allow you to do anything new (they don't), it is that they introduce a new way of modeling with objects, a different way of thinking and of structuring your code.

IMO, the ideal Cor (even if it is a future Cor), should be extensible enough to allow me to support things like Class::StateMachine::Declarative on top of it. And that means, controlling the class build process, including adding support for new keywords inside the class { ... } blocks, and then, also controlling what happens when some method is called or some object slot accessed.

To be fair, as far as I know, Class::StateMachine is the only class in CPAN besides those related to C3 resolution, making use of the mro hooks. That may be an indication of how unneeded a MOP is, or maybe it is just that it is to hard to use and that's why nobody is using it, who knows!!! But for me, Perl has been always about flexibility, a language that can be twisted to suit the programmer, not the other way around and so... I want a MOP!

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.