On Mon, 21 May 2001, Jonathan Scott Duff wrote:
> 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'.
>
> 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
First of all, thanks for putting this table together; this is good way to
clear all the up.
Second: I'm afraid that even after all this discussion and puzzling over
this table for a bit, I'm still a bit baffled by this stuff. Perhaps I'm
just slow, but let's assume for the sake of argument that I'm not the only
one still scratching his head. Could we revist the idea of alternate
syntax to disambiguate between value and variable cases? Perhaps now that
we've freed up the '->' we could use that to access properties on the
variable, while '.' continues to be for the value (since that is more
consistent with other usages of '.', such as $foo.callSomeMethod() ).
Then the table above would look like this (note that this does away with
the (+spot).bark syntax that some people feel is ugly):
> 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
Third, a question about the table above. (+spot).bark evaluates to the
value properties, yes? So, shouldn't the 'arf' and 'Error' be switched
for 010?
Dave
