James Mastros wrote:
$x = 42;
$a = \$x but false;
$b = \$y but blue;
Assuming you meant \$x in the last row we are dealing with three values:
42 but true
42 but false
42 but blue
Which are not identical but equal. The first value is not necessarily
implemented that way because the boolean value can be calculated on demand.
And $a and $b none the less manage to change the value in $x when new
values are assigned to them, and these can be retrieved via $x. If you meant
true not blue in the last line than $b =:= $x.
$a =:= $b ???
If it's true, then the =:= operator is pretty useless -- two things that
are =:= to each-other can have very different semantics. If it's not,
then there needs to be some other way to tell. $$a =:= $$b feels sane
to me. So does $a == $b.
I think =:= shall supersede the $ chains in front of refs by always
dereferencing through to value level and accumulating traits while doing
so. Usually you don't even know how many levels of indirection there are.
I generally don't like it when things half-smudge important differences.
Me neither.
--
TSa (Thomas Sandlaß)
