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.
Of course, old-style blessed objects *can* have C<is> properties, if they're
created with them:
method new ($class: $name, $rank, $snum) {
my %self is Proper('teed') =
( name=> $name, rank=>$rank, snum=>$snum );
return $class.bless(%self);
}
> An instance, itself, doesn't have postIt style properties.
Not sure what you mean by "postIt style". In my view, *all* properties are "PostIt style"...to the extent that they are stuck loosely on the variable or value to which they're ascribed.
Damian
