http://qs321.pair.com?node_id=11118812


in reply to Re: Modernizing the Postmodern Language?
in thread Modernizing the Postmodern Language?

Objects. The semi-announcement that they'll put Cor in the Core is a good thing (as long as Cor actually delivers on its promises)

Actually, getting Cor into the core now that backward compatibility is going to be broken, IMO, doesn't make too much sense.

Moose creator, Stevan Little, pursued for a long time the idea of adding a powerful, modern and feature rich native OO framework to Perl, IIRC, he went into creating several prototypes, but time after time he hit the backward compatibility issue an at the end he throw in the towel (BTW, I recommend revisiting its Perl is not Dead, it is a Dead End talk as it is quite relevant to this discussion).

Ovid, who is a very clever but also practical guy, instead of persuading the perfect, but unrealisable OO system took a different view: could we get something that is useful, simple, cover most use cases and could be implemented without pervasive internal changes or breaking backward compatibility? And he come to Cor, which IMO is very good given the constraints, but definitively not state of the art.

So, in summary, we are getting the no-so-good solution now that the rule that had been making the really-good-ones infeasible is going to be lifted!

Replies are listed 'Best First'.
Re^3: Modernizing the Postmodern Language?
by Ovid (Cardinal) on Jul 12, 2020 at 08:11 UTC
    And he come to Cor, which IMO is very good given the constraints, but definitively not state of the art.

    Hi salva. Thanks for your kind words. Version 1 of Cor is definitely trying to hit the “Minimum” in “Minimum Viable Product” because we don’t want to find ourselves building on a Jenga tower. That being said, when you say “not state of the art”, I would love to hear your thoughts on that. In particular, can you share solid examples of what you think state of the art should be?

      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!

Re^3: Modernizing the Postmodern Language?
by WaywardCode (Sexton) on Jul 02, 2020 at 14:23 UTC

    Re: the dead end talk, thanks for that, I'll definitely check it out. I'm entirely ignorant of those prototype efforts, but am curious now how they compare to Cor.