On Tue, Nov 15, 2005 at 11:23:49AM -0800, Larry Wall wrote:
> On Tue, Nov 15, 2005 at 02:11:03PM -0500, Aaron Sherman wrote:
> : All of that is fine, as far as I'm concerned, as long as we give the
> : user the proviso that chained buts might be optimized down into a single
> : cloning operation or not at the compiler's whim, but it could be a nasty
> : shock if it's not documented, and it's a rather ugly amount of overhead
> : if we don't allow for the optimization.
>
> The situation will probably not arise frequently if we just give people
> the opportunity to write
>
> my $a = $b but C | D | E | F;
>
> instead, or whatever our type set notation turns out to be.
If adding a but involves calling some code to initialize the
but-iness (I don't know if it does myself), that code might
inspect or operate on the item that is being modified in a way
that would be changed if a previous but had not yet been fully
initialized. So, the initialization code for each of the buts
(if any) should be called in order. Reblessing for each one
would only matter if the subsequent but code used introspection
and varied its actions depending on the blessed state.
The choice between:
my $a = $b but C | D | E | F;
and:
my $a = $b but C but D but E but F;
might be used to control the short-cut initialization (which,
would have to be an explicit definition rather than an
optimization since it could have different meaning).
--
