Re: Chained buts optimizations?
On Tue, Nov 15, 2005 at 03:43:59PM -0500, John Macdonald wrote: : 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). 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
Re: Chained buts optimizations?
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). --
Re: Chained buts optimizations?
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
Re: Chained buts optimizations?
On Tue, 2005-11-15 at 12:30, Luke Palmer wrote:
> On 11/15/05, Aaron Sherman <[EMAIL PROTECTED]> 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).
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.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: Chained buts optimizations?
On 11/15/05, Aaron Sherman <[EMAIL PROTECTED]> 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
