Damian Conway <[EMAIL PROTECTED]> writes: > Dave Whipp wrote: > >> OK, I've assimilated all that (though it still feels wrong). I think you are >> saying that of the following, the 4th is an error. >> my @d = @x but Foo; # error: no values involved in this assignment > > Correct. Although presumably this: > > my @d = @x »but« Foo; > > is okay. > > >> I think that the thing that confused is that C<is> Vs C<but> distinction was >> introduced as compile-time vs run-time. It seems that this distinction is >> not relevant. > > Let's say it's an approximation to the true. > > >> Lets see if I apply this to objects. Objects are variables > > Yes. > > >> (they contain attributes). > > Yes. > > >> All access to objects is via (scalar) references: > > Yes. > > >> these references, being values, can have C<but> properties. > > Yes. > > >> When a method is invoked on an object, that method has an invocant, >> which > > enables the method to see the C<but> properties on that reference. > > Yes. > > >> If an object wants to have properties that apply to all references > > (to a given instance), then that property must be defined as an attribute >> of the object. > > Yes. At least, for the new "opaque" objects. Because there's no way > to ascribe the necessary C<is> property to them.
Bugger. I was hoping that Perl 6 was going to make a Pixie like Object database easier to write; looks like I'm wrong. One of the things Pixie does is to attach its control data by magic to the object itself (rather than any particular variable pointing to it). This lets us do all sorts of useful stuff without invading the object since we know that it will carry our metadata around it. Please, consider making <but> properties attach to the target of a pointer rather than to the pointer itself. And if you don't want to do that, I'd say that there is a need to be able to specify some new kind of property that does attach to the target. -- Piers
