in reply to Re^2: Thoughts on new 'class' OO in upcoming perl
in thread Thoughts on new 'class' OO in upcoming perl

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

[download]

— Ken

Replies are listed 'Best First'.
Re^4: Thoughts on new 'class' OO in upcoming perl
by haj (Vicar) on Mar 08, 2023 at 19:04 UTC
    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");

    [download]

    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.

[reply]
[d/l]

In Section Meditations