> Fine, that's a value property, because $ARGS is a simple scalar
> variable that doesn't particularly care that it's pointing to a magical
> filehandle object.
>
> : my $string = "value";
> : print $string.value; # prints 'value'
>
> That seems a bit odd, since .value is a no-op, unless you want to
> differentiate the variable prop hash
Right, what I'm saying is that when you say:
print $a;
and
print $a.prop.value;
you are saying the same thing, ie: *everything* associated with a variable
is actually a property. Which is in turn an attribute of a scalar object. ie:
'property' == 'attribute of special value "prop"'.
> You've set a variable property there, so any value in it will appear to
> be permanently true. So the following would not do what you want:
>
> sub myfunc { return 0 is false }
>
> my $num = 0 is true; # sets variable "true"
> $num = myfunc(); # sets value "false"
> print $num.true; # still prints 1, known at compile time
And this seems the best argument against splitting hairs and making two separate
things. Its extremely confusing. I'd rather that my $num = 0 is true; first
clear out all properties of '$num', then add a property for its 'true' ness. ie:
before:
$num =
{
val => 1
true => 0
whatever => 1
}
$num = 0 is true;
After:
$num =
{
val => 0
true => 1
}
> In fact, the optimizer would turn that into
>
> print 1;
But why? What value does having an immutable property hold? I personally would
want to be able to modify my variables and their properties as they went along.
I could see the value of a compile time check to see if all my ducks were in a
row, ie: that a given property is actually there, a function is actually defined
or what-not. But to make something immutable for the sake of being immutable,
well, convince me what value that would have.
> : print %{$num.prop} # prints all of the properties/attributes associated
> : # with an object.
>
> Which object? There are two of them, both with the name $num. Usually
> this is not an issue, because lvalue context means the variable, and
> rvalue context means the value. In this case, we need to distinguish
> the objects some other way.
that's what I'm saying... that this whole distinction between the two sides is
silly. That an '=' should do a copy by value.
What do you do with cases like:
my $num = 0 is true;
print $num.true;
$num = 0 is not true;
print $num.true;
?
And if this is something different than:
my $num = 0 is true; # sets variable "true"
$num = myfunc(); # sets value "false"
print $num.true; # still prints 1, known at compile time
Why?
> It's really important to keep variable properties separate from value
> properties, especially when you temporize a variable:
>
> our $foo is variablemagical;
> $foo = 1 is valuemagical1;
> {
> temp $foo = 2 is valuemagical2;
> ...
> }
>
> After the temp, $foo is still variablemagical, and valuemagical2, but
> it's not valuemagical1 again until the temp scope is exited. Even
> Perl 5 has to be careful about which magics it localizes and which
> ones it doesn't. Tainting belongs to the value, and tying belongs
> to the variable.
Well, I'd say that in this case, that $foo is *not* variablemagical and that
it does *not* inherit either the 'variablemagical' and 'valuemagical' attributes
at all.
hence:
our $foo is variablemagical;
$foo = 1 is valuemagical1;
{
temp $foo = 2 is valuemagical2;
print $foo.prop.variablemagical; # not true.
}
print $foo.prop.variablemagical; # true.
after all, right now in perl5 you don't 'inherit' anything with the keyword
local: its a simple scratchpad variable that lasts for the duration of the
scope.
This interpretation of properties seems to me just as plausible as yours;
that they are *run time* notes appended to a given variable and can be changed
at runtime as such. This keeps it simple, anything more complicated is going to
get confusing...
Ed
