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▀)



Reply via email to