Re^5: perl 5.38: can the body of a class declaration contain arbitrary code?

Careful, that is misleading. The field initializers run before ADJUST, regardless of the order in which they are written. This has been specified in the Corinna RFC and is how it is implemented. I don't see it specified in the docs, though, which is a bad omission and should be fixed for 5.38.1. Demo code here:

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

class WithACounter {
    my $next_count = 1;
    ADJUST {
        say "Next count in ADJUST: $next_count";
    }
    field $count = do {
        say "Next count in field init: ", $next_count;
        $next_count++;
    };

    method count { $count }
}

say "Next count in the object: ",WithACounter->new->count;
[download]

Output:

Next count in field init: 1
Next count in ADJUST: 2
Next count in the object: 1
[download]

Given that, then it would appear that Scala-like class definition is possible; one simply has to wrap any statements other than my/field in ADJUST blocks.

This is true. Since $count = $next_count++; is an initialization with a side effect (incrementing a class variable), I would also move that into the ADJUST block. It is the only way to get it executed after other code in ADJUST.

Comment on Re^5: perl 5.38: can the body of a class declaration contain arbitrary code? Select or Download Code

Replies are listed 'Best First'.
Re^6: perl 5.38: can the body of a class declaration contain arbitrary code? by jdporter (Paladin) on Jul 05, 2023 at 22:35 UTC
The field initializers run before ADJUST, regardless of the order in which they are written. Well that just fscking sucks. It makes Scala-like code impossible. May as well just declare all the `field`s and then put all the code in one ADJUST block. :-#	[reply] [d/l]
Re^7: perl 5.38: can the body of a class declaration contain arbitrary code? by cavac (Prior) on Jul 07, 2023 at 09:34 UTC
Sorry for the rant below, these are just my own, very heated, views on the topic. I've already banned "class" from all my projects. It's way to inflexible. Can't decide WHEN to call new() on the parent class Can't return undef from new() when init fails, meaning a `bla->new() or handleerror()` doesn't work. The "can't decide what to return from new()" problem also means factories will have to stay with the old package approach. Renaming new() to something else (connect() for example like in DBI) requires workarounds. No multiple inheritance and no partial classes. I sometimes use that to combine helpers and base classes to reduce code duplication and clutter Child classes can't access variables ("fields") of the parent unless declared public. So i would declare ALL fields public to lessen code rework and headaches further down the line. Which defeats the entire purpose of the new C++ style class system. While i generally like the style of declaring class variables and them the functions contained, the new `class` system feels way to restrictive and limited. And as we discussed in Thoughts on new 'class' OO in upcoming perl, i think the approach of "it's good for newbies, and later they can upgrade to using bless" is complete nonsense. As i've stated before: In my opinion, the ability of a language should suffice for experts, but at the basics should be easy for novices to learn. Without limiting their ability to use already learned stuff later when they start to climb their ladder to become an expert. As it stands now, "class" simply doesn't qualify. It introduces an artificial ceiling that requires re-learning Perl OO (using bless) and a complete rewrite of your code when the problem you need to solve gets more complex. I don't want to step on anyones toes, but `class` seems to be designed and optimized to look pretty and modern, functionality be damned. Which, in a way, is funny because people like me switched to Perl not because of how pretty it looks but because it has a much more flexible approach to, well, everything. The ability to bend the language to the problem, not the other way around. I also find the idea somewhat funny that a new, "more readable" OO system will attract new users because it makes the code easier to read. Pretty much every book on Perl introduces inline regular expressions in like chapter 2 and array slices/map/grep in chapter 3. If people can learn that stuff without running for python, blessy OO in chapter 10 isn't going to turn them away, either. XS in chapter 15 might be a different story, though... Yes, Perl could certainly use a more modern OO that is build into the language. But it should be at least as flexible as what we already have, but easier to use. Make it easier to learn, yet enable the experienced experts to bend it to whatever edge case requirements come up today. PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP	[reply] [d/l] [select]