Damian Conway wrote:
> 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:
>
> my $var is Purpose("var demo") = 1 is Purpose("val demo");
>
> print $var.Purpose; # prints "var demo", not "val demo"
>
> To be sure of getting the value's property instead, we simply I<evaluate>
> the variable first:
>
> print (+$var).Purpose; # prints "val demo", not "var demo"
I would like to respectfully point out that the above-proposed semantics is a kind
of maintainence-action-at-a-distance. Suppose I first write a program where $var
has no properties, but at some point the value has the property Purpose, which I
refer to as $var.Purpose . Then, much later, the variable $var is changed (at the
top of the program) to have the property Purpose. $var.Purpose now means something
completely different, namely the variable's property, not the value's. Now, since
I didn't know that when I wrote it the first time, and since my program worked and
now doesn't, this is a long-range dependency bug, or
maintainence-action-at-a-distance. This could easily happen if the value comes
from one program, and $var is in another, written and maintained by two different
people (Unless I mis-understand how properties propagate along with values into and
out of function calls. Do they?)
Lets suppose that I program defensively and I want to always guarantee that I'm
always getting the value's property and not the variable's. Then I will always
write (+$var).Purpose. First, I think it can be argued that this is much uglier
than the $var->{value} syntax that we used to use (under more restricted
circumstances). Second, properties of a variable can be thought of as part of its
"type". Most programming languages get along fine never allowing a type to change
while values change often. Such a similar syntax for such different meaning seems
odd.
Thus, I would like to suggest a more simple solution: use different syntax for the
different semantics. Perhaps "." for value properties and "has" for variable
properties. This syntax would also allow the verb "has" to have a *declarative*
meaning, rather than attempting to change it to an *imperative* as I hear people
doing. That is, "$var has Purpose" would have an "=="-like meaning, not an
"="-like meaning. Perhaps the reader will recall that in English, "let have" is an
imperative, whereas "has" is a declarative.
Epilogue: I notice that it was rather a bit of effort to write the above paragraphs
and keep my English straight as to whether I was talking about the properties of
the variable $var or of the value of $var. I submit that the fact that it is
difficult to talk clearly about this should be a red flag. Mixing program and data
as we are (also called "level-crossing") is very powerful, but making it so
difficult to syntactically disambiguate between them is a recipe for debugging
pain.
Your constructive comments are welcome.
Daniel Wilkerson
