develooper Front page | perl.perl5.porters | Postings from June 2021

Re: Not an OO RFC, take 2

Thread Previous | Thread Next
mah.kitteh via perl5-porters
June 21, 2021 07:11
Re: Not an OO RFC, take 2
Message ID:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, June 21st, 2021 at 1:14 AM, Ovid via perl5-porters <> wrote:

> On Monday, 21 June 2021, 02:01:17 CEST, Chris Prather <> wrote:
>> That's the starting point in the discussion of Corinna. That's the irreducible
>> piece that if you throw out everything else we still would need to discuss.
>> Even if you strip away everything else from Corinna you still need something
>> like (with apologies to John Harper[2]):
>> ```
>> package LasersAndFeelings;
>> use strict;
>> use warnings;
>> use experimental 'class';
>> use experiemntal 'signatures';
>> use Games::Dice 'roll';
>> class Character {
>> has $style;
>> has $role;
>> has $number;
>> sub new($class, $s, $r) {
>> $style = $s;
>> $roll = $r;
>> $number = roll '1d4+1';
>> return bless(__INSTANCE__, $class);
>> }
>> sub attempt_move($s, $num_dice=1) {
>> my $dice = [roll '1d6' x $num_dice];
>> my $count = scalar grep { $_ > $number } $dice->@*;
>> for ($count) {
>> if ($count == $number) { return 'LASER FEELIGNS' } # !!!
>> if (0) { return 'FAIL' } # critical fail
>> if (1) { return 'PARTIAL'} # complication
>> if (2) { return 'SUCCESS' } # everything's fine
>> if (3) { return 'BOON' } # critical success!
>> }
>> }
>> }
>> ```
>> The bare minimum is a new kind of scope, a new kind of state, and a new kind of
>> reference to hold it.
> I've seen you write `sub new ...` a couple of times an even more stripped-down version of Corinna. When I was ripping things out for the MVP, I found myself asking a few questions.
> - How do we get the behavior I'm removing?
> - Can we safely add the behavior back after the MVP?
> Your constructor is a great example of something we shouldn't do, for two reasons. If you read the construction detail (pseudo-code at, you see that superclass constructors are called for you, as they should be. The variable assignment is done for you, as it should be. These are extremely important design goals because anything the language can do safely, it should. Perl devs should stop needing to wire things together manually. It's grunt work that distracts from what we're actually trying to do. That's why I didn't remove the `:reader` and `:writer` attributes: we shouldn't devs creating have multiple broken implementations with different ideas about how they should work.
> Further, if we use this stripped down version, we can't add new() back into Corinna safely without potentially breaking a lot of code that already has new(). Worse, we're trapped with `sub` instead of `method` because switching to that later means that people using older versions of Corinna suddenly find it won't work with newer versions because Corinna doesn't allow you to call subs with the $object-> syntax. It actually knows the difference between subs and methods.
> This was part of the "irreducible complexity" I've struggled with.
>> This is much more stripped down than the Corinna proposal because Curtis was
>> worried he needed to have feature parity with Moo/se otherwise people wouldn't
>> adopt the new system.
> Aside from the fact that people have said this (sometimes yelled this) to me often, this isn't entirely true. See my discussion above about creating an irreducibly complex MVP. Also, consider that I removed `:builder`. This pissed off some people, but I still contend it was the right thing to do. (
>> After two decades of defending it,
>> I now believe Perl's existing object system is a shambles and makes writing clean
>> scalable code more difficult than it should be. We need to take the lessons we have
>> learned from Moo/se and others and improve upon them. That's a problem perl5-porters can solve.
> You want to know whose object system is a shambles? Python. It's a steaming pile of ones and zeros. The addition of dataclasses helps, but seriously, Python's OO is a joke. But nobody in Python reaches for better solutions because Python's OO is core. And they're kicking our ass.

Python's also kicking our ass in things like heavily funded application areas, just to add to the poop-pile. It's been said often that many people would prefer to use Perl for things like machine learning and "big data", but they have to use Python because of the enormous support available. I think there are quite a few lessons to learn with Python's OO - I can't properly make the claim, but I've heard others bemoan something related Python lambda functions not being useful with their OOP - which I think are really just what we know as "anonymous" subroutines.

If what I am reading is tending towards a lot of new code paths and other fundamental things in perl core (like a new SV structure thing), I'd like to add that in addition to "things the language can do safely" that "anything the language can do "real OS" _thread_ safely, it should". Is that out of scope? Yes. Is it out of scope to try to not make things impossible to make thread safe in the future? I don't think so, but I could be wrong. Honestly, I'd use any feature of Perl/perl if it offered some window into light weight threading, even if this meant I learned to write proper OOP code.

Finally, I'd like to just mention that testing is greatly aided by the ability to mock things. I even find it handy occasionally to skip a constructor and pass in a string of the package directly, e.g.,



my $foo = bless {}, q[Foo};

What are the thoughs on this kind of subversion? I suppose this goes into the "introspection" bucket. In any case, it's handy but strikes me as something that fundamentally violates data encapsulation.


> Best,
> Ovid
Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About