One of my worries (for lack of any better term) is that maybe at best it's an xkcd 927 situation and J Random Perlhaxor is now going to need to know how to do OOP TASK X / Y / Z in n+1 ways depending on the specific project/the ecosystem being used/the phase of moon.
That's a valid concern. However, Cor is designed to be part of the language itself, not an alternate object system to choose from. Thus, you could reach for Moo, Moose, Mu, Class::Std, Class::Tiny, Class::InsideOut, etc, but if Perl's built-in OO system satisfies your needs, why make your life harder aside from backwards-compatibility?
We need to end this mess where new developers ask how to do OO and the response is "first, learn how to use a CPAN client; second, pick one of the myriad OO systems on the CPAN; third, here are common installation errors; fourth, well, that OO system isn't well-known, so maybe pick my personal favorite; sixth ..."
In reply to Re^2: Cor—An object system for the Perl core
by Ovid
in thread Cor—An object system for the Perl core
by Ovid
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |