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

Re: Not an OO RFC, take 2

Thread Previous | Thread Next
Ovid via perl5-porters
June 21, 2021 07:41
Re: Not an OO RFC, take 2
Message ID:
On Monday, 21 June 2021, 04:37:53 CEST, Tom Molesworth via perl5-porters <> wrote:

> On Mon, 21 Jun 2021 at 10:02, Chris Prather <> wrote:
>     On Sun, Jun 20, 2021 at 8:35 PM Tom Molesworth <> 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

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?

IT consulting, training, specializing in Perl, databases, and agile development 

Buy my book! -

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