Front page | perl.perl5.porters |
Postings from June 2021
Re: Not an OO RFC, take 2
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, June 20th, 2021 at 12:44 AM, Ovid via perl5-porters <firstname.lastname@example.org> wrote:
> Responding to earlier comments, here's an even more terse version:
> We need an effective OO system in the Perl core. bless is not an effective OO system. With 80+ OO "variants" on the CPAN, and with even the best of them hobbled due to limitations in the Perl language itself, it's time to rectify that. Corinna is a large effort with input from many top-notch Perl devs on what an effective OO system would look like.
> Would P5P be receptive to an RFC?
I can't speak for p5p. But personally, I'd rather see a series of RFCs that introduce fundamental core capabilities that will come together to provide this "effective" OOP in Perl, rather than a kitchen sink take-it/leave-it approach. This is one reason things fail around here, the idea that prometheus is just going to show up and give us the answer. I've never seen that happen here, or anywhere.
I am suggesting this because I DO want to see Perl/perl improved out of this. The question is, what's the most efficient process for discovering the "best" or "least worse" way to extend "bless"?
And any RFC should probably begin with a break down of what "bless" _does_ and what it gives us, e.g.:
* associates a string package name to a trad reference
* gives runtime some hint as to where to find a method when a deref method call is made
* prepends the package name as a string to any deref method call
* enables some kind of inheritance via @ISA, UNIVERSAL::
Surely given the "little OOP system that could" we have now, there are some things that could be done seamlessly to really beef it up properly.
Perhaps in defining what it actually is, we can identify what is missing and therefore work deconstructively to what most seem to want. I do find it interesting that the limited nature of "bless" still gives enough of a feel of OOP that it still requires significant effort to argue that Perl needs a "real" one.
> IT consulting, training, specializing in Perl, databases, and agile development
> Buy my book! - http://bit.ly/beginning_perl