Front page | perl.perl6.language |
Postings from May 2001
Re: properties
Thread Previous
|
Thread Next
From:
Damian Conway
Date:
May 21, 2001 13:45
Subject:
Re: properties
Message ID:
200105212045.GAA46685@indy05.csse.monash.edu.au
Scott Duff wrote:
> > $bar is Open;
> > $bar is Open("from 5pm");
> > $bar{soom} is Open("from 5pm");
> > "bar" is Open("from 5pm");
> > 1 is Open("from 5pm");
> >
> > Note that in the first three of the above cases, it's the I<value in the
> > variable> -- not the variable itself -- that has the C<Open> sticky-note
> > attached to it.
>
> How do we know it applies to the value and not the variable?
Variables can only be ascribed properties in a declaration.
> Is it the presence of "my" that would make the difference?
Exactly.
> What about these:
>
> our $food is ready; # compile-time?
Yes.
> temp $erature is rising; # run-time?
Yes.
>
> And if it is the "my" that makes all the difference, this will need
> good documentation (and appropriate warnings):
>
> sub CheckBar { ... return my $bar is Open; }
"Useless use of variable property at line..."
> > You may also be wondering what happens if a variable and the value it
> > contains both have a property of the same name. The answer is that we
> > always get back the variable's property in preference to the value's:
>
> So, if I have a Dog $spot, here's a little table where a 1 in the M
> column means $spot has a bark method that says 'woof', 1 in the V column
> means $spot has a bark variable (compile-time) property that says 'arf'
> and a 1 in the A column means $spot has a bark value (run-time) property
> that says 'yip'.
Except that it would be the object reference in $spot that had the run-time
property.
> MVA $spot.bark (+$spot).bark
> 000 Error Error
> 001 yip yip
> 010 arf Error
> 011 arf yip
> 100 woof woof
> 101 woof woof
> 110 woof woof
> 111 woof woof
>
> yes?
Yes.
Damian
Thread Previous
|
Thread Next