Front page | perl.perl6.language |
Postings from January 2003
Re: More Array Behaviors
From:
Dave Whipp
Date:
January 27, 2003 14:59
Subject:
Re: More Array Behaviors
Message ID:
20030127225954.15829.qmail@onion.perl.org
"Damian Conway" <damian@conway.org> wrote in message
news:3E35AD49.1000004@conway.org...
>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.