Re: Thoughts on new 'class' OO in upcoming perl

[kcott]

G'day cavac,

++ Thanks for this meditation.

I was looking at class a week or two ago (when I first noticed v5.37.9 had been released). I had thought that I might install v5.37.9 to check it out (with actual code tests) but decided against that for two reasons:

• Being "experimental and very incomplete"^{[perlclass: TODO]}, it could easily change in v5.37.10 (or later).
• A stable v5.38.0 was just a matter of weeks away and I would be installing that anyway. (I've been installing at least v5.x.0 for many years now.)

"... i think this new system shouldn't give up any of the flexibilities ye olde 'bless' provides."

Perhaps unintentionally, you have spoken (in various parts of your post) as if class was intended as a replacement for bless. As ++haj wrote: "bless isn't going to go away".

Given "It [class] isn't a bless wrapper, but a completely new system built right into the perl interpreter."^{[perlclass: History]}, it would be interesting to benchmark bless-based and class-based new() functions.

Currently, a class uses a '.../lib/Some/Class.pm' file which starts with 'package Some::Class;' (and, yes, I acknowledge that's an oversimplification). One of the things that I was interested in testing was whether simply changing 'package' to 'class' would still work in the current framework (e.g. @INC variable, parent pragma, 'SUPER' pseudoclass, and so on).

The current documentation for class is extremely sparse. Given most of the documentation is in perlclass, the addition of a link to that should be a bare minimum. It does say that it "behaves similarly to package" but doesn't go into any detail beyond "... except that the newly-created package behaves as a class." — that strikes me as vague and terse, albeit accurate.

[haj]

I understand that the warnings of being experimental and very incomplete are a bit scary. I'll write a separate article about what's missing in core OO, maybe with a frequently edited head article which will get smaller and smaller over time.

Yet, your article rises some interesting questions.

• ...it would be interesting to benchmark bless-based and class-based new() functions.: I've tried to do this with one of my pet classes (which is not on CPAN because it is almost identical to Math::Vector::Real) in an application which creates hundreds of thousands of objects and couldn't find any significant differences. And I don't think this is too surprising. By the way: For this particular class, I consider a blessed array reference (i.e. no Moo* stuff) still to be an excellent alternative, but the current development state of core OO doesn't allow a comparison for complex classes yet.
• One of the things that I was interested in testing was whether simply changing 'package' to 'class' would still work in the current framework...: There's quite a lot which just works after that change.
  • @INC variable: No problems here. The resolution mechanism between classes (which share their namespace with packages) to files is the same.
  • parent pragma: No. The hierarchy is defined in the class declaration like :isa(Parent::Class). Trying use parent ... fails with an error message Modification of a read-only value attempted at /home/haj/localperl/lib/5.37.10/parent.pm line 22. . The message might deserve some tuning, but the "read-only value" is actually the @ISA of your new class. Core OO populates that array, but makes it readonly for the rest of the world.
  • 'SUPER' pseudoclass: Works as usual.
• The current documentation for class is extremely sparse. True! This is a known issue. Eventually, this chapter of perlfunc should be self-contained, with a link to perlclass. I admit that I tried to prepare a PR for that but got stuck between things which are still technically possible but ought to be forbidden (like having both a package and a class with the same name).

[kcott]

G'day haj,

++ Thanks for looking into the points I raised and providing feedback.

There wasn't anything that was actually "scary", at least for me. I usually try out experimental features privately when they first appear; I won't use them in production (personal, $work, or even PM code) until the experimental status is lifted. I wasn't too surprised with "very incomplete": I took class to be the first step in a staged implementation, wholly or partly, of Corinna.

What you wrote about parent presumably also applies to base and any code that manipulates @ISA (either directly or via a module).

That's an interesting point about package and class names. I had wondered about that but didn't list it with things I was interested in testing. Forbidding duplicate names seems appropriate; although, presumably something like this would be valid (even if it is poor design):

class X;
...
package Y;
...
class X;
... extend the class here ...

[haj]

What you wrote about parent presumably also applies to base and any code that manipulates @ISA (either directly or via a module).

Correct! In core Perl OO, @ISA is set to readonly as soon as the class declaration has been processed. I think it makes sense to maintain the value for reading.

About your code example: That construct is currently a syntax error. Once a class has been "closed" by ending the enclosing block, file, or like in your example by opening another namespace with package Y;, that namespace is "sealed":

Cannot reopen existing class "X"

Everything else would be at least messy (consider e.g. conflicting parent classes or version declarations). And while this is a restriction compared to the sloppy package rules, I can not imagine a problem which can be adequately solved by re-opening a class.

There is a bit of a grey zone. Code like this is "valid":

use 5.37.9;
use feature 'class';
no warnings 'experimental';

class X;

field $f :param;

method normal {
  say '$f = ', $f;
}

#----------------------------------------

package X;

sub creepy {
  my $self = shift;
  say @_;
}

package main;
my $x = X->new(f => "Hello, world");
$x->normal;
$x->creepy("Goodbye, friends");

So, as of today, you can re-open an existing namespace as a package, as always before. Subroutines can be written like old-style "methods" in that package. They are resolved as expected You can even override a method. The method gets the core OO object as its first parameter. But in those creepy methods you do not have access to the fields of the class with the same (nor can you write them as method, to begin with). Having code implanted into the namespace does not give special access to the object.

Perl 5 is not known for being eager to prohibit creepy code, so I guess it will stay that way.

[LanX]

> (like having both a package and a class with the same name).

Please excuse my ignorance, if it's not for speed, why else?

What is the incentive for those parallel structures instead of building on top resp. wrapping around existing ones?

Like a class is a special package, a new is blessing a hash, etc ...?