Re: Cor—An object system for the Perl core

in reply to Cor—An object system for the Perl core

I am really, really looking forward to that. I'm pretty sure I'll use it for new modules as soon as it is available.

As for the reasons, I'll just follow the points raised by 1nickt and explain why my opinions are different.

An OO framework in the core is what I expect from a contemporary programming language. I'll expand on this in the last point.
bless is fine, but not a framework, and the many degrees of freedom it provides make things complicated when you maintain sources written by different authors. Including packages written by myself if I look at them five years later.
The syntax is unPerlish was my first reaction when I attended my first presentation about Moose. Well, technically this isn't even true since Moose itself is Perl, working with Jurassic Perl or better. Nonetheless I decided to give it a try, and I found the benefits well worth the learning curve. I'll do the same when Cor is available, only that this time I'm following the discussion and I know what to expect.
(I don't care for the name, so this is just to keep the sequence)
Today I am happily using Moo or Moose, though I found that there are a few things which I don't like. In my opinion Cor did nicely build on the lessons learned from Moo*. Some of my itches are:
- It isn't core. This may be just a formality, but the fact that it isn't core makes it just one of the many OO systems bolted upon Perl 5. It turns out that Perl has a lot of experienced developers, and many of them are pretty opinionated which of them is the Only True one. I hope that an OO system in core will be the primary choice in the future. It won't be perfect for me, maybe it won't be perfect for anybody, but given the open discussion Ovid is moderating here I am optimistic that it will be a system most of us can live with quite fine.
- The syntax is a bit clumsy. I guess that this can't be avoided if you want to run it on Jurassic Perl, and I still find it amazing that it is possible to implement Moo(se) with the feature set of Perl 5.8. In core, an OO system can do better.
- The has function is overworked (I seem to recall that there's an article by Ovid about that but can't find it right now). With plain bless, parameters for object creation and object attributes were totally independent (which means you have to code it all by hand), with Moo* everything needs to occur in has (or as a fallback munged in BUILDARGS).
- An object system in core will be faster than Moo*.

That said, I'm also curious how and when PPI, PPR and the various editor modes will recognize and support Cor.

Comment on Re: Cor—An object system for the Perl core

Replies are listed 'Best First'.
Re^2: Cor—An object system for the Perl core by Ovid (Cardinal) on May 20, 2020 at 21:30 UTC
The has function is overworked ... With plain bless, parameters for object creation and object attributes were totally independent (which means you have to code it all by hand), with Moo* everything needs to occur in has (or as a fallback munged in BUILDARGS). They're totally independent for Cor. `has $data;` only declares instance data. That's all. Absolutely nothing else. The optional attributes describe other aspects of the class. I worked very hard to make sure that was correct. As an aside, even pure-Perl Cor will be faster that Moo/se, but I can't say much more about that right now. Cheers, Ovid Hire me for training or software development.	[reply]
Re^3: Cor—An object system for the Perl core by Your Mother (Archbishop) on May 21, 2020 at 12:56 UTC
As an aside, even pure-Perl Cor will be faster that Moo/se, but I can't say much more about that right now. Everything is faster than Moose so… For my part, the syntax and its power look nice. All seems quite well thought out; what I skimmed on the wiki sounds terrific. I would maybe still argue it’s better on the CPAN—even if there is core support necessary to go with it—before the core to gauge adoption and suitability. If it’s good—appropriate, doesn’t drag a bunch of stuff down because of core changes—it will see quick adoption and clean-up and such making it even better for the core. If not, it will avoid a lot of fights, core issues that could be rolled back, and problems going forward. I’d like to hear what people like dave_the_m think about it. Sidenote: This is the first I’ve heard about it and I find that a little troubling though I understand that opening everythig up to committee is a good way to prevent progress.	[reply]

In Section Perl News