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

Re: Not an OO RFC, take 2

Thread Previous | Thread Next
From:
Ovid via perl5-porters
Date:
June 21, 2021 07:41
Subject:
Re: Not an OO RFC, take 2
Message ID:
521852883.1182386.1624261268993@mail.yahoo.com
On Monday, 21 June 2021, 04:37:53 CEST, Tom Molesworth via perl5-porters <perl5-porters@perl.org> wrote:

> On Mon, 21 Jun 2021 at 10:02, Chris Prather <chris@prather.org> wrote:
> 
>     On Sun, Jun 20, 2021 at 8:35 PM Tom Molesworth <tom@deriv.com> wrote:
>     >
>     > Interesting as this suggestion is, I don't think this can be called an irreducible piece at all - Object::Pad already exists without inventing these primitives, and has the advantage of being compatible with existing classes.
>     >
>     > What you're proposing seems to be a parallel, *incompatible* class implementation? If so, I don't see how that would be feasible.
>     >
> 
>     If that's what I'm proposing, I think I have company:
> 
>     "[...] Corinna classses cannot inherit from non-Corinna classes due to
>     difficulties with establishing the base class (UNIVERSAL or
>     UNIVERSAL::Corinna?)."[1]
> 
> If Corinna does take that route, I believe it would be a big mistake....

I need to touch on this one briefly because it was also a strong source of concern in the design. In a nutshell: maybe later we can add in the ability to inherit from non-Corinna classes. But if we provide that ability up front and later realize it was a mistake, we're stuck. Even if we call Corinna an experiment and warn people heavily that the syntax will change, I see this like signatures: people can and will use it in production because the gains are so great that the risk seems worth it.

But I'm *not* ignoring the issue. In fact, Damian suggested an interesting workaround and I kinda like it.

    class Game::Character {
        use Some::ORM;
        has $some_orm :handles(*);

        has $table :reader = 'characters';

        has $character_id ...;
        has $name         ...;
        has $strength     ...;
        has $agility      ...;
        has $wisdom       ...;

        ADJUST {
            $some_orm = Some::ORM->new(...)
        }
    }

In the above hypothetical example, we can't inherit from the ORM class because
it's "vintage" Perl, but we can instantiate the instance in ADJUST phaser and
the `:handles(*)` says "delegate *every* method we don't have to the $some_orm
class."

Yeah, ORMs are probably a lousy example, but the above effectively gets you
inheritance. Want multiple inheritance?

    class Foo {
        use DateTime;
        use Some::Other::Class;
        has $created :handles(*) = DateTime->now;
        has $other   :handles(*) = Some::Other::Class->new($created);
        ...
    }

That's effectively LIFO order MI. It's also a spectacularly bad idea, but we
provide the syntax. (I just hate that `*` is only used here. That feels wrong)

Also, because Corinna knows that subroutines aren't methods, you can't import
&List::Util::sum and suddenly get a broken $object->sum method (no more
namespace::autoclean, the sort of module we write because Perl is so limited).
Thus, if we inherited from DateTime, how would Corinna even know what methods
to call?

Best,
Ovid
-- 
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/. 

Buy my book! - http://bit.ly/beginning_perl



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About