"Damian Conway" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >Anything that "holds" anything is a variable, not a value. > [...] > I'm saying that only scalar *values* can have C<but> properties. > And yes, that includes Array references, but not arrays. > > > My mental image is of variables > > that provide access to values: variables are compile-time, and lexically > > scoped: values are run-time, and (can be) dynamically scoped. > > Not quite. Variables are containers, values are the data they contain. > Compile-time/run-time and scoping are orthogonal to that.
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 @a is Foo = @x; my $b = [@x] but Foo; my $c = @x but Foo; # ArrayRef automagically created my @d = @x but Foo; # error: no values involved in this assignment my @e is Foo := @x; 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. Lets see if I apply this to objects. Objects are variables (they contain attributes). All access to objects is via (scalar) references: these references, being values, can have C<but> properties. 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. 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. An instance, itself, doesn't have postIt style properties. Dave.
