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

Re: Not an OO RFC, take 2

Thread Previous | Thread Next
Tom Molesworth via perl5-porters
June 21, 2021 02:37
Re: Not an OO RFC, take 2
Message ID:
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....

> "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]

... so the wording there could be improved, but fortunately Object::Pad
inheriting from other classes already works. :repr(HASH) is applied
automatically when extending a hashref-based class, for example.

We're actively using this in both directions - lots of Object::Pad-based
code inheriting from IO::Async::Notifier, for example, and in the other
direction there's plain hashref-based OO inheriting from Tickit::Widget
Object::Pad OO which inherits from plain hashref OO again - see for examples.

Method resolution, sub injection plus the usual features such as `->can()`
and `->DOES` Just Work already - so far I've found that the existing
Object::Pad implementation is quite effectively cross-compatible with plain

It's probable that large parts of the core implementation would be based on
this, so I'd hope that this level of compatibility is preserved. If not,
that'd be a much harder sell for anyone who has any existing code.

> 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.

Right - but most classes provide few guarantees about internals. The
guarantees for classes that are intended for inheritance are typically not
much more than "it's a hashref"; the keys could change or someone could
decide that it's time to revisit inside-out objects again. You could say
the same about `->{key}` for any of those: unless explicitly documented,
it's a side effect of the implementation. There are other classes which use
blessed arrayrefs, coderefs, scalar refs or other types... each class has
its own implementation details for that data.

The guarantees are around things like blessed() providing the class name,
ref() returning true, methods available via ->method_name, ability to check
for presence of a method via ->can($method_name)... I'd expect all of these
to be preserved.

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