Should we use field $f = EXPR; syntax?

[leonerd]

I know we had justabout settled on field initialisation expressions appearing in braces, but a troubling thought occurred to me today.

On Defaulting Expressions in Signatures

First, a bit of background about function signatures. Prior to using signatures, it would be common to see code such as:

sub f {
  my ($x, $y) = @_;
  $y //= "default-if-undef";
}

This requires a first parameter to assign to $x, and optionally a second for $y, but if the caller did not pass a defined value (i.e. they passed undef, or they passed nothing at all) then the defaulting expression runs instead. This distinction didn't make it into the first version of signatures. The way that signatures currently work makes the following two roughly equivalent:

sub g($x, $y = "default-if-missing") { ... }

sub g {
   my ($x, $y) = @_;
   $y = "default-if-missing" if @_ < 2;
   ...
}

Because it turns out in practice that actually a lot of the time people care about definedness and not mere existence, there is a proposal to add syntax using //= instead. Thus, the following would be more equivalent to the first function above:

sub f($x, $y //= "default-if-undef") { ... }

My recent addition of named parameter support to ADJUST blocks in Object::Pad has already hit upon this annoying distinction. I did want to provide default values using this kind of syntax, but again it turns out that the simple implementation cares about existence rather than definedness. In particular, in this code:

https://metacpan.org/dist/Device-Serial-SLuRM/source/lib/Device/Serial/SLuRM.pm#L249

Somewhat paraphrased:

ADJUST :params(
   :$baud = undef,
) {
   $baud //= 115200;
   ...
}

This is pretty icky, and all because elsewhere in the container script I use Getopt::Long to handle commandline arguments:

GetOptions(
   'baud|b=i' => \my $BAUD,
   ...
);

my $slurm = Device::Serial::SLuRM->new(
   baud => $BAUD,
   ...
);

Were instead we to have a similar syntax for ADJUST :params that cares about definedness then this entire problem goes away. Most likely that would also be spelled with //=.

On Field Expressions

So what does this have to do with fields? Well, it becomes a problem when we want to run a field defaulting expression whenever the parameter was not defined (i.e. not present, or present as the undefined value). Right now we cannot; having instead to resort to plain ADJUST blocks which look a bit messy and disconnected in the same way the $baud variable is above.

field $f :param { undef };
ADJUST {
   $f //= "default-if-undef";
}

This feels a bit awkward and circumspect. If the syntax for attaching defaulting expressions on fields used = then we would have a convenient place to put a //= operator instead. This would have the huge advantage of preserving Perl's "similar things look similar" behaviour, which I think is important.

field $alpha :param = "default-if-missing";
field $beta :param  //= "default-if-undef";

However, this does have to be weighed against the problem that now field and my behave very differently in what look like similar circumstances. Try explaining to someone why the output of this is what it is:

class C {
   my $one = say "This is printed once";
   field $two = say "This is printed three times";
}
say "This happens inbetween";
C->new for 1 .. 3;

generates:

This is printed once
This happens in between
This is printed three times
This is printed three times
This is printed three times

However - overall I am beginning to prefer = and //= as an idea, over {...}. Using = means that //= is even possible even if we have to explain that field and my happen at different times; whereas if we stick to {...} then I don't think a syntax for //=-like behaviour is even very possible. If it is it would look quite different to function parameters and ADJUST blocks.

Can anyone see a way out of this one?

[rabbiveesh]

On the necessity of // defaults

This is pretty icky, and all because elsewhere in the container script I use Getopt::Long to handle commandline arguments:

GetOptions(
   'baud|b=i' => \my $BAUD,
   ...
);

my $slurm = Device::Serial::SLuRM->new(
   baud => $BAUD,
   ...
);

Were instead we to have a similar syntax for ADJUST :params that cares about definedness then this entire problem goes away. Most likely that would also be spelled with //=.

While I like the idea of a defined-or initiator, this particular case could be helped by having a call-site syntax for excluding pairs when the value is not defined.

On the mental strain involved

However, this does have to be weighed against the problem that now field and my behave very differently in what look like similar circumstances. Try explaining to someone why the output of this is what it is:

I'm not sure how much this bothers me mentally. field is a new keyword, which is run for every object. There's a reason it's not my, which belongs to the class. If we DIDN'T have this distinction, we'd run into the opposite problem, that however we'd make class data would be surprising.

The way it is now, my works just like it did when your file started with package instead of class. New behavior is limited to new keywords

[leonerd]

While I like the idea of a defined-or initiator, this particular case could be helped by having a call-site syntax for excluding pairs when the value is not defined.

I don't know if the syntax works, but perhaps it could be spelled key ?=> $value, to mean (defined $value ? ( key => $value ) : () )

If that syntax doesn't work maybe there's some other spelling which does.

[HaraldJoerg]

I am not concerned about field and my behaving differently: That's why they are different keywords. They have different
scopes where they are valid, too: my $f; $f = 123; is fine, field $f; $f = 123; is a syntax error.

In #77 we discuss several examples where individual constructor parameters don't map directly to fields, and I'm wondering how the field $f = EXPR syntax would look in those cases. With the block syntax, constructor parameters can be made accessible within the block, and it is visble where their scope ends. We could adopt the method for declaring "which constructor params make up this field" from #77, but the actual use of these parameters would introduce yet another type of scoping: "Declared constructor parameters are valid only in EXPR."

Taking a step back: I guess that the "default-if-undef" situation is more frequent than nontrivial parameter mappings, and therefore more relevant for a replacement by a declarative syntax. We could declare the stuff from #77 as "too ambitious" for now. Nontrivial mappings between constructor parameters and fields can still be done in ADJUST.

[Ovid]

However, this does have to be weighed against the problem that now field and my behave very differently in what look like similar circumstances. Try explaining to someone why the output of this is what it is:

class C {
   my $one = say "This is printed once";
   field $two = say "This is printed three times";
}
say "This happens inbetween";
C->new for 1 .. 3;

---

I would argue that we already have this distinction:

sub C {
    my $one = say "This is printed three times";
    state $two = say "This is printed once";
}
say "This happens before";
C() for 1..3;

Admittedly, the timing of things are a touch different, but when someone sees, for example, the various attributes attached to a field (not to mention the field keyword itself), I think they'll learn pretty quickly what the difference is. my is an artifact of the language, while field is part of the class. It's like that long reply on blogs.perl.org where @thoughtstream was explaining that my variables don't work as class variables because they're an implementation detail and not a formal part of the class definition (which makes them useless for a MOP).

So I suspect that this will largely be a matter of educating people on OO and reminding them that a top-level my in a class definition, outside of a method, probably isn't what they want.

[thoughtstream]

@leonerd observed:

• field $name {BLOCK} provides a neat scope for spontaneous lexicals and a place
  to attach NCA specification, but does not permit us to ask for the //= param behaviour
• field $name = EXPR; lets us neatly ask for //=, but doesn't neatly contain
  spontaneous lexicals and makes NCA specification much harder.

Any other ideas?

Perhaps we’re being overly seduced by the convenience of the //= and ||= syntaxes?

The raw block initializer and :adjust($NCA) initializer syntaxes give us clean
scoping and a reasonable place to inject NCA declarations, but no apparent slot
to specify when they should initialize: on non-existence, on non-definedness,
or on non-truth.

But maybe there is a convenient (pseudo-)slot in which to specify those distinctions.
Maybe we just need more precise attribute names:

    # Initialize from r/g/b NCAs if colour NCA missing...
    field $colour :param        :adjust(:$r,:$g,:$b) { Colour->new( r=>$r, g=>$g, b=>$b ) };
                                #######

    # Initialize from r/g/b NCAs if colour NCA undef...
    field $colour :param  :adjust_undef(:$r,:$g,:$b) { Colour->new( r=>$r, g=>$g, b=>$b ) };
                          #############

    # Initialize from r/g/b NCAs if colour NCA false...
    field $colour :param  :adjust_false(:$r,:$g,:$b) { Colour->new( r=>$r, g=>$g, b=>$b ) };
                          #############

Then, if your initializer block doesn’t require any other NCAs, but you still want it to run
when the field’s own NCA is undef or false (rather than when it's non-existent),
you write:

field $colour :param  :adjust_undef { $DEFAULT_COLOUR };

field $colour :param  :adjust_false { $DEFAULT_COLOUR };

Admittedly, those are not as compact as:

field $colour :param  //= $DEFAULT_COLOUR;

field $colour :param  ||= $DEFAULT_COLOUR;

...but the attribute-block versions are arguably more readable
and certainly more cleanly scoped.

And there’s nothing to say that the three operator versions couldn’t still be supported as well
(on the principle of TIMTOWTDI), as shorthands for the underlying attribute-block mechanisms:

    field $colour :param       :adjust { $DEFAULT_COLOUR };  # Initialize when missing
    field $colour :param             =   $DEFAULT_COLOUR  ;  # Same (shorthand)

    field $colour :param :adjust_undef { $DEFAULT_COLOUR };  # Initialize when undef
    field $colour :param           //=   $DEFAULT_COLOUR  ;  # Same (shorthand)

    field $colour :param :adjust_false { $DEFAULT_COLOUR };  # Initialize when false
    field $colour :param           ||=   $DEFAULT_COLOUR  ;  # Same (shorthand)

That would mean that you can use = EXPR, //= EXPR, or ||= EXPR in the most common cases,
and fall back on :adjust, :adjust_undef, or :adjust_false when you need to reap other NCAs,
or when your initialization requires more than a single expression, or just whenever you're feeling
verbal rather than symbolic.

If we took this approach then I would strongly suggest not allowing
a raw, un-attributed initializer block at all:

    field $colour :param { $DEFAULT_COLOUR };   # Error: did you mean  :adjust { $DEFAULT_COLOUR }

That syntax was always iffy in terms of Perl's existing grammatical structure, not to mention psychologically.
(E.g. note how, in the above example, the raw initializer block feels like it's somehow associated with
the preceding – and entirely unrelated! – :param attribute? That's because blocks in Perl are
almost always preceded by some kind of identifying keyword: sub, for, do, package, BEGIN, etc.)

So it would be more consistent with existing Perl syntax (and with JAPH intuitions) if initializer blocks
were never raw, but always needed to be introduced by a relevant keyword-ish construct;
namely by an :adjust, :adjust_undef, or :adjust_false.

BTW, I’m not especially attached to the names :adjust_undef and :adjust_false,
and would be perfectly content if we can find better ones. That said, they are at least
fairly consistent...and helpfully explicit about the conditions under which they are
supposed to be invoked.

[aquanight]

Had something of a bit of an idea here.

With regard to adjust/adjust_undef/adjust_false ... why attack this from the side of adjust, specifically?

I'm thinking two things:
1: Add the missing/undef/false selection logic to :param instead of :adjust, possibly by using NCA signature syntax in :param but allowing only a single scalar (which is assigned to the field). Simple bareword name could be retained as equivalent to :$name.
2: Add some kind of syntax to our named parameters signature to say "reject this parameter if the value is undefined/false". One idea I want to float on this is to leverage next which would otherwise have no legitimate purpose here.

Basically in an :adjust signature you could have:

• :$name -> Require this NCA to exist (with any value, even undef) for this adjust block. If the NCA is absent or already consumed, the adjust block fails to bind (see later).
• :$name = EXPR -> Supply 'value' if NCA is missing.
• :$name //= EXPR -> Supply 'value' if NCA is undef or missing.
• :$name ||= EXPR -> Supply 'value' if NCA is falsey (0, "", undef, missing)
• $name //= next -> Require this NCA to be defined. If the NCA is undef or missing, the adjust block fails to bind.
• $name ||= next -> Require this NCA to be truthy. If the NCA is falsey (0, "", undef, or missing), the adjust block fails to bind.
  (next was chosen, specifically because something like $name //= die would just result in construction failing, without trying any alternatives. One is certainly free to do that if they wish.)

:param and :adjust are tried in lexical order, left to right. The first one to successfully bind executes to populate the field and the assignment-initializer expression (field $f = EXPR;) doesn't run. (An :adjust containing (possibly vacuously) no required NCAs always successfully binds, so it could be an error to have any :param or :adjust after it, or an initializer expression.)

If a :param or :adjust fails to bind, none of its NCAs are consumed and neither the block nor any default expressions run. We try the next :param or :adjust, in left-to-right order. If no :param or :adjust successfully binds, the initializer expression runs to populate the field. If one is absent, construction fails. (What error do we give? I'm thinking go by the first thing we tried, since it'll usually be :param in practice.)

In theory this could allow:

• Multiple :param, allowing an NCA to have aliases.
• Multiple :adjust with blocks, for different ways to compose a parameter.
• :adjust before :param potentially.
  In practice though, I expect most will have one :param and one :adjust, in that order.

If an :adjust block fails to bind, none of its NCAs are consumed and the block doesn't run, and we try the next :param or :adjust entry for that field. If we run out, a field lacks an assignment initializer and has at least one :param or :adjust attribute, then at least one :param or :adjust block must successfully bind for construction to succeed, and in the case multiple could bind, the prevailing option is the "leftmost": the first such option to bind would consume its NCAs and execute, and no :adjust or :param following it will even be tried. This would call for a field to have potentially multiple :adjust blocks but I expect the primary use case is at most one :param and at most one :adjust and that's all that's really needed.

For :param itself, we could allow simple names to be equivalent to ':$name' but the idea would be to allow a signature - provided it consists of exactly one scalar, possibly annotated in any of the ways above.

Then our color/r/g/b scenario could look like this:

field $colour :param(:$colour //= next) :adjust(:$r, :$g, :$b) { Colour->from_rgb($r, $g, $b); } = Colour->getDefaultColor;

(If we end up not liking signatures in :param, then the above could just be spelled with: :adjust(:$colour //= next) { $colour } and we'd have to definitely relax the idea of "only one :adjust per field".)

Result:

• If colour NCA exists and is defined, regardless of existence of any of r/g/b, :param binds and then drops it straight into the field (:param basically exactly equivalent to :adjust(:$name) { $name })
  -- In the event some or all of r/g/b exist, they would behave as unconsumed NCAs. (Possible alternative: :adjust blocks following the selected :params/:adjust can consume their NCAs if they can bind, but still don't run their block, nor do they run "default expressions".)
• If colour NCA is absent or undefined AND all three of r, g, and b NCAs exist, then the adjust block binds and Colour->from_rgb composes the value of $colour.
• If colour NCA is absent or undefned AND any of r, g, or b NCAs are absent, neither :param nor :adjust bind and the assignment expression supplies the value of $colour.
  -- If at least one of r/g/b is present, they would behave as unconsumed NCAs.

[thoughtstream]

@aquanight has a lot of interesting (and really good) ideas here
...especially moving the assignment operators into the parameter declarations.
But I think there are still issues with this proposal.

The main issue being that both @aquanight’s proposal,
and my own previous suggestion, still both seem too ad hoc,
piecemeal, and overly complicated. They both have too many
moving parts and too much syntax. It really seems to me that
there must be a simpler and cleaner solution for this issue,
a unified initialization model that we’re collectively
still failing to discover.

I think @aquanight has provided a critical piece of the puzzle though,
which suggested to me something like the following...

What if there were no adjust attribute (nor adjust_undef nor adjust_false)?
What if there were only param?

Except that there can now be multiple param specifiers,
each with the following syntax:

:param (PARAMLIST) {CODE}

The PARAMLIST specifies which NCA(s) the initializer requires (and consumes).
Parameters in the PARAMLIST can have defaults (via = or //= or ||=).
If no explicit default value is specified for a given parameter, the implied default is: = next.
A call to next within any default expression in a PARAMLIST immediately moves
the initialization process along to the next :param of the same field, without consuming
any of the NCAs for the :param that’s being abandoned. If there is no next :param,
the initialization of the field fails and an exception is thrown.

The CODE block specifies the final value with which the field is to be initialized
(i.e. in the usual way: the initializer value being the final value evaluated within the block).
The block has access to the NCA value(s) that matched the parameter(s) specified
in the corresponding PARAMLIST.

So now, if you want to initialize the $colour field from the 'colour' NCA (if it exists),
or else from the 'color' NCA (if it exists), or else from the 'r'/'g'/'b' NCAs
(if they exist), or else with the global $DEFAULT_COLOUR, you write:

field $colour :param(:$colour)      { $colour                          }
              :param(:$color)       { $color                           }
              :param(:$r, :$g, :$b) { Colour->new(r=>$r, g=>$g, b=>$b) }
              :param()              { $DEFAULT_COLOUR                  };

And if the desired constraints are that the 'colour' or 'color' NCAs must be defined
and that the 'r'/'g'/'b' NCAs must be non-zero, then that becomes:

field $colour :param(:$colour //= next)                        { $colour                          }
              :param(:$color  //= next)                        { $color                           }
              :param(:$r ||= next, :$g ||= next, :$b ||= next) { Colour->new(r=>$r, g=>$g, b=>$b) }
              :param()                                         { $DEFAULT_COLOUR                  };

Except, of course, you already HATE this proposal...because that’s far too much typing,
especially for the common cases. Damian just made everything much worse. Typical! :-(

So we also allow parts of the syntax to be omitted: various combinations of the PARAMLIST,
the CODE block, and even the :param attribute itself. With the following equivalences:

:param(:$NAME         )           --->    :param(:$NAME        = next) { $NAME      }
:param(:$NAME   = EXPR)           --->    :param(:$NAME        = EXPR) { $NAME      }
:param(:$NAME //= EXPR)           --->    :param(:$NAME      //= EXPR) { $NAME      }
:param(:$NAME ||= EXPR)           --->    :param(:$NAME      ||= EXPR) { $NAME      }

:param          = EXPR            --->    :param(:$FIELDNAME   = EXPR) { $FIELDNAME }
:param        //= EXPR            --->    :param(:$FIELDNAME //= EXPR) { $FIELDNAME }
:param        ||= EXPR            --->    :param(:$FIELDNAME ||= EXPR) { $FIELDNAME }

:param                 {CODE}     --->    :param(:$FIELDNAME   = next) { CODE       }
:param                            --->    :param(:$FIELDNAME   = next) { $FIELDNAME }

                = EXPR            --->    :param()                     { EXPR       }
              //= EXPR            --->    :param()                     { EXPR       }
              ||= EXPR            --->    :param()                     { EXPR       }

                       {CODE}     --->    :param()                     { CODE       }

Or, more succinctly:

• If the :param is omitted , it defaults to :param() (and must be the final alternative).
• If the PARAMLIST is omitted, it defaults to the field name.
• If any parameter’s =///=/||= is omitted, it defaults to = next,
• If the CODE block is omitted, it defaults to the value of the (explicit or implicit) parameter.

So now, our first example becomes:

field $colour :param
              :param(:$color)
              :param(:$r, :$g, :$b) { Colour->new(r=>$r, g=>$g, b=>$b) }
              :param()              { $DEFAULT_COLOUR                  };

And our second:

field $colour :param(:$colour //= next)
              :param(:$color  //= next)
              :param(:$r ||= next, :$g ||= next, :$b ||= next) { Colour->new(r=>$r, g=>$g, b=>$b) }
              :param()                                         { $DEFAULT_COLOUR                  };

And the common usages become:

    # Required NCA of same name as field...
    field $colour :param;

    # Optional NCA with default when missing...
    field $colour :param   = $DEFAULT_COLOUR;

    # Optional NCA with default when undef...
    field $colour :param //= $DEFAULT_COLOUR;

    # No NCA used at all...
    field $colour          { $DEFAULT_COLOUR };

    # No NCA used at all (made explicit)...
    field $colour :param() { $DEFAULT_COLOUR };

Overall, this approach seems to cover every case – and to unify just about every syntax! – that we’ve previously considered,
via a single (albeit highly abbreviable) construct.

That said, I'm still not entirely satisfied with this design.
I still feel like there are too many syntactic alternatives here.
I’d be happier if the abbreviation table were smaller, maybe just:

:param                            --->    :param(:$FIELDNAME   = next) { $FIELDNAME }
:param(:$NAME         )           --->    :param(:$NAME        = next) { $NAME      }
:param(:$NAME   = EXPR)           --->    :param(:$NAME        = EXPR) { $NAME      }
:param(:$NAME //= EXPR)           --->    :param(:$NAME      //= EXPR) { $NAME      }
:param(:$NAME ||= EXPR)           --->    :param(:$NAME      ||= EXPR) { $NAME      }
:param                 {CODE}     --->    :param(:$FIELDNAME   = next) { CODE       }

Or, in other words:

• You can't omit the :param attribute.
• If you omit the PARAMLIST, the parameter has the same name as the field.
• If you omit the CODE block, the field is initialized from the (explicit or implicit) parameter.

But, of course, that would make the some of common cases more verbose (though also more explicit):

    # Required NCA of same name as field...
    field $colour :param;

    # Optional NCA with default when missing...
    field $colour :param(:$colour   = $DEFAULT_COLOUR);

    # Optional NCA with default when undef...
    field $colour :param(:$colour //= $DEFAULT_COLOUR);

    # No NCA used at all (must be explicit)...
    field $colour :param() { $DEFAULT_COLOUR };

Sigh. It’s hard to know just how to find the right balance
between convenience and ETOOMUCHSYNTAX.

[aquanight]

I think the ETOOMUCHSYNTAX problem is best alleviated by keeping :adjust as the "general-purpose", and let :param, and suffix initializers, be the special but common cases. After all, it means the difference between a field that just has an initial value, and one pulling from an NCA with a default value, are spelled similarly:

field $two = 2;
field $colour :param = $DEFAULT_COLOUR;

Fields initialized from a more complex block, and fields defaulted from a more complex block, also look similar:

field $user :param;
field $work_directory :param(:$work_directory //= next) :adjust { my $def = $ENV{HOME}."/tmp"; -d $def || mkdir $def ? $def : "/tmp/" }; 
field $user_shell :adust { my $sh = "/bin/sh"; open my $fd, "</etc/passwd"; while (<$fd>) { my @F = split /:/, $_; shift(@F) eq $user and $sh = $F[5]; } close $fd; $sh; }

It's perfectly fine to not try to have one attribute do everything and result in blowing up the syntax rules. We have way too many "trying to do everything" syntaxes in perl as it is. So we should favor syntax rules that make the common cases look more common.

The rules get simpler when :adjust always requires a block, :param doesn't allow a block (since it just pulls from its one NCA always). :param() looks weird, but :adjust() is no different from an ADJUST phaser.

[thoughtstream]

I concede all of @aquanight's points above.

But see also my new "recantation" post at the very end of this discussion.

[thoughtstream]

Short answer: Yes, we should use = DEFAULT – and add //= DEFAULT – for field initialization.

Long answer: Yes, we should definitely use = DEFAULT – and add //= DEFAULT – for field initialization. ;-)

The fact that:

field $NAME = $DEFAULT;

...executes the = at a different time from a regular assignment is (as has been pointed out by others above)
completely covered by the prior art of:

my    $VAR   = $VALUE;
state $VAR   = $VALUE;
sub ( $PARAM = $DEFAULT) {...}

...especially that last case.

The loss of:

field $NAME :adjust(:$OTHERNAME) { ... }

...is (as @HaraldJoerg) notes) a minor one, since we still have:

field $NAME; ADJUST :params(:$OTHERNAME) { $NAME = ... }

That’s an acceptable pessimization in my view, given the far greater need for consistent and flexible default initializations,
compared to the likely infrequent need for these kinds of “nontrivial parameter mappings”.

(Though, of course, the ADJUST version syntax should really be:

field $NAME; ADJUST (:$OTHERNAME) { $NAME = ... }

;-)

[thoughtstream]

“Your scientists were so preoccupied with whether or not they could
that they didn"t stop to think if they should.”
-- Dr Ian Malcolm, Jurassic Park

Well...after a day of soul-searching, a good night’s sleep,
and discontinuing the cold medication I have been taking,
I’d like to take a step waaaaay back and revisit this entire question.

My most recent proposal was a complex three-part :param specifier,
with thirteen (!) syntactic variants, capable of defining
contingent multi-stage field initializations based on the
existence, definedness, and/or truthiness of multiple NCA sets.

Now that the Benedryl has worn off, I have come to feel that such a design
fails not only Malcolm’s Dictum, but also Occam’s Razor, and – most importantly –
the original mandate of the PSC for a minimal initial design.

Because the various proposals we’re now discussing
seem an awfully long way from “minimal”.

So what is the minimal useful behaviour?
I think it’s just two things:

• A :param specifier to indicate that the field is initialzed from a single NCA
  (with an optional argument to specify that the NCA has a different name from the field).

• An = EXPR default to indicate how the field is to be default initialized if no :param is specified,
  or if one is specified but there is no corresponding NCA. The EXPR has access to $self and
  any other fields declared before the current field, but not directly to any NCA.

And that’s it.

With those two, we get all of the following:

    # Uninitialized field (i.e. value is undef)...
    field $colour;

    # Field initialized from 'colour' NCA...
    field $colour :param;

    # Field initialized from 'color' NCA...
    field $colour :param(color);

    # Field initialized with constant...
    field $colour = Colour->new(r=>0, g=>0, b=>0);

    # Field initialized from another field...
    field $background = $colour->complement();

    # Field initialized from a method of the object...
    field $background = $self->get_colour->complement();

    # Field initialized from a complex block of code...
    field $background = do { my $bg = Colour->random_colour();
                             while (contrast($colour, $bg) < 0.25) {
                                 $bg = $bg->offset(('r','g','b')[rand 3] => rand(256));
                             }
                             $bg;
                        };

    # Field initialized from NCA or from an expression if the NCA is missing...
    field $background :param(bg) = $colour->complement();

...which is surely enough for an initial minimal feature set.

For the time being, any more complex initialization requirements should be handled
in an ADJUST phaser, or perhaps by a NEWARGS phaser (if we actually decide
to add those at some point), or by defining a :common method as a pseudo-constructor.

I guess I don’t really mind if the = EXPR has an //= EXPR alternative,
to distinguish the absence of a required NCA from the undefinedness of that NCA.
Though that alternative could (almost) as easily be provided by:
ADJUST { $fieldname //= EXPR }

But that’s as far down the slippery slope of featuritis as I think we should
let ourselves slide...at least for the moment. We’ve conceived grand visions
of powerful initialization mechanisms, but in the process we’ve forgotten
that grandeur and power are not the brief here. At least, not initially.

I’m sorry that I forgot that mandate myself, and more especially
if I enticed or encouraged others to forget it as well. :-(

[Ovid]

@aquanight I hear what you're saying and I have a lot of sympathy for it, but I think it's not the time.

Using $self, $class, or __CLASS__ in initializers defeats the benefits of using purely declarative code. Using $self in ADJUST can be problematic depending on where ADJUST is defined. By saying 'Define your "initializing" method just before the field that's using it," that's suggesting a best practice (which I kinda like) but having to tell developers "remember to write your code just so" puts us back into the problem of "if only developers would learn to code well ..." and so much of Corinna was designed around the philosophy of "make it natural to code well."

Telling developers to "code well" works if you're mentoring someone one-on-one and have plenty of time to give the developer feedback, but we've seen repeatedly that this does not scale to the masses. On the plus side, this means I get paid more money for consulting when I'm called in to fix the resulting mess, but that's not a technical argument I can make :)

Also, you mention overriding a base class's "initializing" method, but I've written before why this is not a good idea. If we had types and typed signatures (including return values), this would be less likely to be an issue. Design by contract, especially validating pre- and -post conditions (and maybe invariants, but those are problematic), could also help there, but people aren't going to use it (that includes myself. We have deadlines, confusing constraints, working around rubbish code, etc.). Tests also aren't a solution because people are really bad at testing and trying to explain Liskov doesn't sink in.

For now, I think Corinna should be conservative. We shouldn't be providing thing that we know are problematic. Instead, let's see where we get with a better, safer system. Trying to do too much in these corner cases could paint us into a corner and the design team has worked really, really hard to avoid that.

[HaraldJoerg]

@Ovid, @aquanight This needs some care. The criticism was about using $self and instance methods in field initializers and not about using them in the ADJUST phaser. This is a relevant distinction: The ADJUST phasers of all modules (roles and classes) run after the field initializers of all modules, regardless of where in the source they are declared.

I agree that calling class methods might be problematic in a field if that field is defined as :common , I overlooked this. I guess these can be handled sufficiently by order of declaration because class field initialization is not affected by ADJUST blocks nor by constructor params.

If instance methods are called in initializers, then no ADJUST processing has been taken place. So, for example, array and hash fields are uninitialized (they can't be initialized directly from :param ) and user provided values have not been validated. That's icky and in my opinion enough reason to avoid it. Whether it needs to be prevented... I'll leave that to politics.

However, preventing $self from being used in ADJUST phasers should not be required and would be an annoying obstacle. All field initializers have been processed at that time. This is not only about overriding initializer methods: I have an application where a role has an array field which is initialized by the consuming class, different consuming classes provide different values. So this is a method required by the role. In Moose, a class could directly initialize the role's field, but the Corinna encapsulation prohibits this.
Yes, this would also permit overriding a base class's initializing method, but preventing it would be too patronizing.

[Ovid]

@HaraldJoerg I think I'm misunderstanding something. You wrote:

This is a relevant distinction: The ADJUST phasers of all modules (roles and classes) run after the field initializers of all modules, regardless of where in the source they are declared.

And they run in the order declared, but that's not true of methods. So if the ADJUST phaser can call a method, we have no guarantee that a subsequent phaser might set up some critically necessary data that will alter a method's behavior, but since that phaser hasn't been run yet, the method behaves in an unexpected manner.

This is why I suggest not allowing $self in ADJUST. However, that presents the problem you have: sometimes you need to call methods, but you want to ensure the instance is set up correctly. While I am loathe to suggest changes to Corinna at this point, perhaps a new phaser is worthwhile: FINALIZE. It's guaranteed to be called after all ADJUST phasers, but before the instance is returned to the consumer. It's analogous to Moose's BUILD method and would allow $self to be injected.

By not cramming too much responsibility onto ADJUST and making a clear distinction between adjustments and finalization, I think we satisfy everyone's concerns. If I've misunderstood, please let me know.

[HaraldJoerg]

@Ovid ADJUST phasers run in the order declared, from parent to child, with the phasers of their roles in hopefully well defined places. If a phaser sets up necessary data, you need to make sure that it runs before these data are used by other ADJUST phasers, whether these use them directly or by calling a method.
The method will not behave in an unexpected manner if the sole purpose of the method is to return a suitable initial value for a field. I know that we have no syntax to distinguish such a method from every other lifetime method, but this is something I can live with.
A new phaser won't actually help too much: If a field can not be initialized in ADJUST, then calling a method in FINALIZE might still hit the same problem.
My take on this: Constructing an object from a parameter list is a process which might take several steps. In traditional Perl OO, this was what we wrote in sub new { ... }. In Corinna, ADJUST needs to cover up for all things which were in new and can't be declared elsewhere, similar in purpose to BUILD in Moose. BUILD is an overridable method, which is OK, since a Moose method can access the whole object. In Corinna, the fields of each module are encapsulated, so each module needs its own ADJUST phaser to fix its own fields. And then, I need some mechanism which allows a class to initialize a field defined in a role it consumes or in its parent class. In Object::Pad, methods are a feasible way to do this, so my expectation is that Corinna allows the same.

[leonerd]

We verymuch have to allow $self in ADJUST, for all of those "about to finish the constructor now" tidying-up sort of tasks. If you think there should be another phase for it because this isn't late enough yet, then we end up just rolling out an ever-increasing sequence of block names for it. That doesn't sound very sustainable. In any case, most of the original reason for having ADJUST after the field assignments like this was indeed to rely on that. All of the fields of all classes run, before any of the adjust blocks of even the base class.