Damian's excellent blog post includes this comment about Dios:

The only three problems with Dios are:

• It’s not built-in to Perl itself, so its performance is suboptional;[sic]
• It’s not built-in to Perl itself, so it requires a huge amount of extremely complex multi-layer code to make it feel as if is;
• It’s not built-in to Perl itself, so it's merely one possible choice amongst the vast and incoherent array of entirely reasonable alternatives already on CPAN.

While the first 2 problems are objective, the third gives some pause for thought.

As JAPH, I like choice. TIMTOWTDI is as close to being the Perl motto as anything else. There are indeed a plethora of class/object/role systems on CPAN. Probably I've only even heard of half of them, used maybe 5% of them and happily continue to use 1% of them.

The concern here is that if/when a class/object/role system is merged into the language itself, what consequence does this have for all those alternatives on CPAN and all the other code (on CPAN and elsewhere) which depend on them? Will development or maintenance of them cease? Will vast swathes of code have to be rewritten as those modules become unmaintained? The problem is not just with 1% of the modules either because my 1% is highly unlikely to be your 1% which will differ in turn from everybody else's 1%.

Perhaps this has already been debated and determined to be a price worth paying. Perhaps I'm overstating the case. Either way I hope the decision to include any such system in the language itself is not one which we shall come to regret down the line.

Corinna isn't being made to disallow Moose or Moo (or Object::InsideOut, Class::Accessor, or whatever else) from working. It's being made to have a sane default in the language that's a bit more modern and more opinionated than blessed data structures and a bit more performant and available than something that sits wholly outside the core.

Could all the object models on CPAN continue to work without Corinna? Yes. Could they continue to work just the same alongside Corinna? Yes, excepting some might have a keyword collision or two to clear up. Could they embrace Corinna and offer what they choose in addition to what Corinna brings into core? Also, and emphatically, yes.

Will development or maintenance of them cease? Will vast swathes of code have to be rewritten as those modules become unmaintained?

That's a question for the current maintainers of all these modules to answer, and if they don't want to continue maintaining their modules, to the user base. Modules have become unmaintained for a variety of reasons, and "it's now in the core" is not the most frequent one. If no volunteer is found to step in, then it will still take some years until users must rewrite their code since Perl will always value compatibility.

And also, it's a loooong way. The first version of Corinna lacks a lot of features which have been added to e.g. Moose or Moo.

Either way I hope the decision to include any such system in the language itself is not one which we shall come to regret down the line.

We might regret it if we have the expectation that someone else will, without us paying for that, maintain the modules we want forever. But I hope that we are not like that, otherwise I'd say: we deserve no better.

It is indeed a long way off. I am still frequently seeing production environments today using 5.16 and occasionally some as far back as 5.8 so there won't be universal coverage of any to-be-introduced language features for well over a decade after release. The consequences of the decision may not be seen for a long time but once the decision is made it will be very difficult to avert them entirely.

I'm sure that none of us have the expectation of perpetually maintained modules forever, gratis. My concern is that the incentive to maintain an already-widely-used module will likely be reduced if the language is extended to include some/most of the functionality.

The first version of Corinna lacks a lot of features which have been added to e.g. Moose or Moo.

Intentionally so - the docs make a big noise about it being an MVP. Perhaps that is all it will ever be: such that to do anything beyond that minimum would require one of the already extant alternatives. That might just be the best of all outcomes.

---

🦛

«…Will vast swathes of code have to be rewritten as those modules become unmaintained…»

Sure. This will happen. Because of some visions like this i was very unpopular in the famous last company i was with. See also Cassandra for further details. In German we say: «Ich habe es kommen sehen!» It is like in real life: «They» always tell us that «this» will never happen. But shit happens. Like the tragic flood in Germany recently or the total disaster now in Afghanistan. Regards, Karl

«The Crux of the Biscuit is the Apostrophe»

I’m very happy to see this. Thank you Ovid and TheDamian and stvn and everyone else. A fast implementation of meta-object programming in the Perl core? Way cool.

I think we can afford to focus on the positives right now; it’s too early to say that there will be long-term negatives. It’s early days, and whatever the first results of Corinna are, they’ll be built upon. I think Ovid & Co. have been very up-front about the plan to start somewhat smaller and limited and why it has to be that way. Think about where we might be in 5 years. If this project goes well, what will the active Perl world be doing for OO? I suspect it’ll be a mixture of:

• Building software directly on what Corinna has become by then.

• Building software on one or more new, extended frameworks that use Corinna under the hood (in somewhat the same way as our existing frameworks use “Classic” Perl OO under the hood).

• Building new software and maintaining existing software on Moose/Moos/Moo/Mo, Class::Accessor and friends, Class::MethodMaker, Object::InsideOut, Object::Tiny, Class::Prototyped, Class::YourFavoriteHere, and whatever else people feel like using, because all that’s still going to be around.

I feel there’s no reason any Perl fan should be worried about Corrina. Corinna isn’t going to harm Moose or Moo and the many codebases that use them, any more than they harmed Class::Accessor and friends. Classic Perl OO will never go away.

This isn’t to say that I love the current MVP design. I don’t. But that’s OK. (For one thing, nobody asked me.) If Corrina is a success, it will naturally — if not in Core-inna then by way of CPAN extensions — come to somehow support most of what is in the mainstream of current development practice. That’s just the way of things, but also I suspect that only a minority of developers are quite as opinionated as the MVP design is. However, if Corinna proves to be a rock-solid base with speed and power, then other developers will build what they want on that base if Corinna itself doesn’t have what they want. Those extensions will still garner all the advantages that Corrina brings, besides what they (opinionatedly) reject. What’s not to like?

I’ll reply elsewhere with my armchair objections to bits of the MVP.

Edit: I know I'm not the first person to say any of this. In particular, the immutability topic is huge, and its proponents have good arguments. I just don't think they're as universally applicable as some do.

A couple armchair thoughts about where I think Corinna MVP design is too opinionated, bearing in mind that it is an MVP. (I’m more interested in thinking about the larger philosophical issues than quibbling about the MVP proper. I’m nobody, I’m not working on Corrina, I’m not trying to change Corinna.)

1. Only supporting v1.2.3 triplet semantic versioning. It seems to me there are two main versioning patterns among Perl modules: v-string-like version triplets (semantic or not), and decimal numbers like 1.23 (e.g. MAJOR.MINOR where both are integers of arbitrary size, usually small). I understand not wanting to support every variation in Perl module versioning. However, there’s nothing wrong with decimal, and if it’s not the most common method it’s surely close. I don’t think Corinna has to translate one to the other, just support both styles on their own terms and croak if something tries to compare v1.2.3 to 1.23. Not supporting decimal numbers right off the bat seems like a gratuitous incompatibility.

2. No native way to support read/write accessors. (Yes, I understand you can make them with methods if you want them even now.) I wholeheartedly reject that mere use of a read/write accessor is necessarily a “code smell”. It’s a natural way to program and in itself is neutral. (You have to train yourself to think in terms of immutable objects; I’m pretty sure it’s the training that makes most of the difference in the end, not the immutable objects, or separate accessors, or what-have-you.)

   That said, not allowing it does prevent certain mistakes when having to program it manually, but the whole point of a framework is so we don’t have to program it manually. Multi-method dispatch would be cool, but it’s still a cop-out.

I suspect that if Corinna is a success (and I truly hope it will be) those things will be added, the MVP spec notwithstanding. I kinda doubt it’ll get into the Perl core otherwise.

Neither issue dampens my excitement about the project as a whole. I very much look forward to using version 2.0. :D

– Aaron
Preliminary operational tests were inconclusive. (The damn thing blew up.)

You were concerned about Corinna MVP only supporting semver. Please see the README's Principle of Parsimony:

Many things in the proposal are deliberately restrictive, such as Corinna only allowing single inheritance. This is to allow Corinna to be cautious in not promising too much. If we later find this too restrictive, we can allow multiple inheritance. However, if we start with multiple inheritance and discover we don't need or want multiple inheritance, we would break existing code by taking it away. Any proposals to change the RFC must consider the principle of parsimony.

Semver falls under this. If we allow more than semver and it's a mistake, it may be too late to change it. If it's too restrictive, it's trivial to say "we can add support for more version formats."

The MVP isn't designed to take anything away. It's designed to offer something we can play with and find out what works and what doesn't.

Cheers,
Ovid

Hire me for training or software development.

Only supporting v1.2.3 triplet semantic versioning.

I wouldn't go as far as to call it a "gratuitous incompatibility" since there are no Corinna classes right now which would break because of this. But I agree with you that having decimals would be good: Semantic versioning can be an obstacle in early Corinna adoption. If I want to migrate an existing old-style OO class to Corinna while keeping the API, I would need to change from decimal to semantic - and, worse, users of the class might need to change their code, too.

No native way to support read/write accessors.

I'm not sure what you're expecting here? Corinna attributes can be declared to create reader and writer methods, for example:

slot $name :reader :writer

This creates a ->name method to read, and a set_name($new_name) method to overwrite the value, much in the style of MooseX::SemiAffordanceAccessor. You can not use the same name for reader and writer, though (which in my opinion is a good thing).

Ovid, thank you for your job and patience!

It looks like it was a hard way but it was worth it.

I'm looking forward to the release. CORINA encourages to create new projects with PERL!

s/CORINA/Corinna/;
s/PERL/Perl/;

«…getting modern OO into the Perl…

I really wonder if I want yet another promised land. Or another holy grale.

Furthermore, I propose that Perl will be destroyed if you continue 🤪😎

See also Lasagna Code.

Best regards and thanks for further advice, Karl

Was Perl destoyed when require was added? Was it destroyed when use and proper module support supplanted the most common uses of require? What about when the /x flag was added for regexes? Did adding say, pragmas, Encode, perlio layers, or tied variables destroy the language?

How exactly does adding syntax that's been under development and testing as a module for years to the core destroy a language? Did Turbo Pascal destroy Pascal? Did the ANSI C changes destroy C? Did the extensions in glibc and in the GNU coreturils package destroy Unix? Did Bash 4 destroy Bash? Did Bash destroy the Bourne shell? Did adding DirectX, WSL, or Windows Defender destroy Windows? Please explain how in your thinking adding features you're not required to use in your own projects destroys a project. Perhaps I'm being dense today, but I don't see it.

«…Please explain…»

I’ll try it. This quote inspired me:

«As Rob Pike put, "complexity is multiplicative": fixing a problem by making one part of the system more complex slowly but surely adds complexity to other parts. With constant pressure to add features and options and configurations, and to ship code quickly, it’s easy to neglect simplicity, even though in the long run simplicity is the key of good software.» (Donovan, Kernighan 2016, xiii)

Best regards, Karl

«The Crux of the Biscuit is the Apostrophe»

Do what you want with your proposed OO framework, but please acknowledge that it belongs as a competitor with all the others that have come before, some of which are in very widespread use.

Consider whether your fixation on getting your framework adopted into Perl core is based on ego.

Make some software, show it to the community. If it works well, it will be used. What more do you need?

TIMTOWTDI

TIMTOWTDI

Where do you draw the line? We wouldn't have DBI if Sybperl, Oraperl, etc were good enough. Getting DBI meant getting XS in shape so that you didn't have to recompile all of Perl to link to a library via C calling conventions.

Sometimes getting the right thing in the core expands the universe of potential WTDI.

Consider whether your fixation on getting your framework adopted into Perl core is based on ego.

That would be quite some egos here.

Damian Conway, who created several OO frameworks which are available on CPAN, wrote about disadvantages shared by all OO frameworks which are not in the core.

Also, I trust the Perl porters and the Perl Steering Committee that they won't accept it into the core if they wouldn't think it fits.

Why include a TCP/IP stack in your OS? Surely some people use other types of networks. Why include a libc, since clearly there are hundreds of other programming languages? Why include a syslog facility when some apps target some other logging facility or manage log files themselves? Why even have a local filesystem when people can just write to S3? Why ship framebuffer support since everyone eventually installs a vendor-specific accelerated video driver?

Here are some relevant soundbite-sized quotes.

• “Computer languages differ not so much in what they make possible, but in what they make easy.”
• “When they first built the University of California at Irvine they just put the buildings in. They did not put any sidewalks, they just planted grass. The next year, they came back and put the sidewalks where the trails were in the grass. Perl is just that kind of language. It is not designed from first principles. Perl is those sidewalks in the grass.”
• "Perl is designed to give you several ways to do anything, so consider picking the most readable one."
• "Portability should be the default.”
• “Part of language design is perturbing the proposed feature in various directions to see how it might generalize in the future.”
• “A journey of a thousand miles continues with the second step.”
• "Although the Perl Slogan is There's More Than One Way to Do It, I hesitate to make 10 ways to do something."
• “We're really serious about reinventing everything that needs reinventing.”

Do you know who said any of those? They're all from timtoady and I can't think of a better indicator of the Perl nature than its creator. We've had many, many ways to do it. Now there are some pretty good ideas where the paths are in the grass. The language should have a way to do the things we need it to do, to perturb the OO feature in a direction that in this case is already being generalized for the future. It can finally be a a readable way to do things that goes everywhere recent versions of the core language tools will be installed. That will help Perl make OO easy.