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

Re: Not an OO RFC, take 2

Thread Previous | Thread Next
From:
Chris Prather
Date:
June 21, 2021 02:02
Subject:
Re: Not an OO RFC, take 2
Message ID:
CAEFJ168CNDnJCBYHK3KbhfW2Ks1SmD+GiAYCgv3KHEhbyibmZQ@mail.gmail.com
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]

"There are a number of details specific to the case of deriving an
Object::Pad class from an existing classic Perl class that is not
implemented using Object::Pad."[2]

Discussing the feasibility is, I believe, why this thread exists.

I'm possibly wrong, reading XS is not my strong suit, but this appears
to be at least close to what Object::Pad does in practice. Instead of
a custom sv_type (can you make a custom sv_type from XS?), Paul is
blessing a AV ref by default and allowing the user to declare a
representation of a HV ref or an AV using magic for the representation
of slot data as a pad for lexicals within the scope of the class
block. Implementation-wise, yes it's reusing natives at the XS layer
to implement new natives at the Perl layer. So at the conceptual level
this is *exactly* what Object::Pad is doing .. at least as far as I
understand things.

From the docs for Object::Pad:

"Behaves similarly to the package keyword, but provides a package that
defines a new class. Such a class provides an automatic constructor
method called new."

"As with package, an optional block may be provided. If so, the
contents of that block define the new class and the preceding package
continues afterwards. If not, it sets the class as the package context
of following keywords and definitions."

"As with package, an optional version declaration may be given. If so,
this sets the value of the package's $VERSION variable."

Paul is documenting a class as something conceptually distinct from a
package. When it comes to Objects no where does Paul document that
`use Object::Pad; class Foo { has $bar = 1; } say for
Foo->new()->[0];` is expected to work. He explicitly says the opposite
in fact:

"This is an opaque representation type whose contents are not
specified. It only works for classes whose entire inheritence
hierarchy is built only from classes based on Object::Pad."

It seems to me that the fact that it happens to work is a side effect
of the implementation. An opaque representation whose contents are not
specified explicitly isn't an AV ref.

Maybe I have this all wrong. I was basing the ideas I've written in
this thread on the discussions surrounding Object::Pad and Corinna's
development (and on wikipedia's description of metamodernism). So if
I'm that far off I'd love for someone to set me straight.

From where we started, I really would hope that the process of the RFC
helps point to a better implementation than Object::Pad and Corinna's
current expectations. I would love to have these new classes and
instances be able to inherit seamlessly from the existing Perl object
system. There are a number of technical hurdles surrounding that
implementation that are challenging at best, and aren't at all
relevant to the question of: is this even a reasonable goal?

-Chris

[1]: https://github.com/Ovid/Cor/wiki/Corinna-Overview
[2]: https://metacpan.org/pod/Object::Pad#SUBCLASSING-CLASSIC-PERL-CLASSES

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