|laziness, impatience, and hubris|
Re^2: Cor—An object system for the Perl coreby Ovid (Cardinal)
|on May 20, 2020 at 21:24 UTC||Need Help??|
Thanks for your feedback! I'll try to address your points as clearly as I can. You've stated your positions fairly strongly and I may not convince you, but I need to address this for others.
Before I address your points, there's an overriding point which must be taken into account. Barring something going horribly wrong, it's going to be part of the Perl language. People can work to support it or improve it, but stopping it isn't likely. So rather than focus on what you think should be done, maybe focus on what can be done? Help improve it instead of throwing stones.
I see no need to clutter the Perl core with this or any other OO framework.
Perl's core OO facilities are so primitive that there are around 100 or so OO systems on the CPAN trying to "improve" it. Most of them are to scratch personal itches (usually around attribute access) and fall far short of what a robust system needs. What's worse is that most of them are broken in numerous ways.
When I work for clients, one of the main problems they face is the time it takes for their developers to get up to speed on whatever OO system they're using (I often stumble on brand-new OO systems that, again, developers have to learn). Even Python 2, whose OO system is abominable, manages to have just enough of a sugar layer that people have stuck with it. We need that "just enough" sugar layer, but "good enough" isn't good enough if we want to offer something compelling to new developers.
The current options including bless, which is in the core, are more than adequate, and offer choice to the Perl programmer.
bless isn't going away. If you want to drop to that level, go ahead! We're not taking anything away.
The syntax is unfamiliar and IMHO unPerlish.
New syntax is always unfamiliar. I still remember when our was introduced and people were confused about how to use it. And let's not even begin to discuss the debates around Moose, even though Moose and its spin-offs have clearly won the OO war.
As for whether or not it's "unPerlish", that's very subjective. I've worked hard to try to not make it too different and I've been onboarding advice from both new developers and old. The general consensus has been "ok, that leverages things we already know." The objections have been technical. The syntax generally doesn't scare them. I realize that not everyone will agree.
The name is awful, combination of cutsey 21st Century non-word and the British euphemism for God.
The name is not a "combination of cutsey 21st Century non-word and the British euphemism for God." It's short for "Corinna", a love interest of the poet Ovid. But this isn't a real objection and, over time, it will no longer exist because this will be part of the language.
What's wrong with Moo?
Oh, where do I start? Where do I stop?
The Moo/se family of languages have generally won the "OO wars" in the language, but that's only because they were so much better than the alternatives, not that they were the "right" way to approach things. Stevan Little, the creator of Moose, agrees that there were tons of design mistakes made, but that's to be understood in creating something new. Matt Trout, the creator of Moo, agrees, in principle, with many of the design directions of Cor (though we often disagree on implementation details). Let me list some issues.
The above list isn't exhaustive and it's not well-explained because I don't feel like retyping the wiki, many emails, or extensive IRC communications on the topic.
And looking at Moo, it's trivial to add attributes with ro, rw, or rwp. All of those offer the wrong affordance for minimizing the public contract of your object. I'm designing something that's easier for beginners to use, but it also easier for large-scale codebases to manage. Just create a DBIx::Class instance in your debugger and type m $result and be amazed at how many methods it offers. Many of them are helper functions and not methods. Many of them should be private methods that you should never call. Real developers get bit by those things all the time. It's time to end the madness of 100+ object systems and make something that not only works, but offers the right affordances for building solid code.
I realize I may not have satisfied you and that's OK. I don't expect everyone to agree. But even amongst my detractors who are heavily, publicly involved in the language, there's general agreement that Cor is a good way to go.