Chained buts optimizations?

[Aaron Sherman]

This question came out of a joking comment on IRC, but it's a serious
concern. Can chained buts be optimized, or must the compiler strictly
create intermediate metaclasses, classes and objects in the following:

my $a = $b but C but D but E but F;

The difference is between:

my $tmprole = role {
is $b.meta.role;
does C;
does D;
does E;
does F;
};
my $a = $b but $tmprole;

and

my $tmpbc = $b but C;
my $tmpbcd = $tmpbc but D;
my $tmpbcde = $tmpbcd but E;
my $a = $tmpbcde but F;

In the second example, constructors are called 4 times, but in the first
case constructors are called only once.... sort of. Until you get to
taking about constructors on the metaclasses, but metaclass constructors
still make my head hurt.

The same goes for destructors, but I don't think those get to get called
until everything goes away (since there's a reference chain between
them).

--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback

[Luke Palmer]

On 11/15/05, Aaron Sherman <a...@ajs.com> wrote:
> This question came out of a joking comment on IRC, but it's a serious
> concern. Can chained buts be optimized, or must the compiler strictly
> create intermediate metaclasses, classes and objects in the following:
>
> my $a = $b but C but D but E but F;

Certainly. The semantics should precisely equivalent either way
(constructors don't get called during a rebless, I think).

Luke

[Aaron Sherman]

So, are you saying that:

$a = $b but C;

is:

$a = $b.clone.rebless(class {is $b.meta.class; does C;});

? Or are you refering to does instead of but (which creates a new
object)? If you are saying the former, then would:

$a = $b but C but D;

be:

$a = $b.clone.rebless(class {is $b.meta.class; does C; does D});

or:

{
my $_tmp = $b.clone.rebless(class {is $b.meta.class; does C;});
$a = $_tmp.clone.rebless(class {is $_tmp.meta.class; does D;});
}

?

This is where the semantic difference arises, since the constructor
and/or destructor for $b.meta.class might well be something that I
expected to be called multiple times, and won't see.

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.

[Larry Wall]

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.

Larry

[John Macdonald]

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

--

[Larry Wall]

On Tue, Nov 15, 2005 at 03:43:59PM -0500, John Macdonald wrote:

Roles are *supposed* to be well behaved. If there's a difference
between those two notations, it would be that I'd expect the first to
do the normal compile-time collision checking for all the new roles
at once, while the nested form should do run-time mixins at each
step that potentially hide any previous methods of the same name.
You could have intermediate forms like:

my $a = $b but C | D but E | F;

where any E or F methods hide any C or D methods, but it detects collisions
between E and F or between C and D.

Larry