This may go without saying, but ...
If $a === $b means what I think it does, then I believe that a
not-premature implementation optimization of === would be that it
always $a := $b if it was returning true, so that any future === of
$a and $b or aliases thereof could short-circuit with a =:=
On Friday 14 July 2006 00:30, Darren Duncan wrote:
This may go without saying, but ...
If $a === $b means what I think it does, then I believe that a
not-premature implementation optimization of === would be that it
always $a := $b if it was returning true, so that any future === of
$a and
At 12:30 AM -0700 7/14/06, Darren Duncan wrote:
If $a === $b means what I think it does, then I believe that a
not-premature implementation optimization of === would be that it
always $a := $b if it was returning true, so that any future === of
$a and $b or aliases thereof could short-circuit
Darren Duncan schreef:
What I propose concerning non-premature === optimizing is a system
where, at any time that two appearances of the same immutable value
are compared with ===, they are immediately consolidated into a
single appearance.
That should only be done voluntarily. A bit like
On Fri, Jul 14, 2006 at 00:30:20 -0700, Darren Duncan wrote:
This may go without saying, but ...
...
This is a VM issue. It clarifies semantics, and the runtime VM may
choose to do this freely for simple values (but not for objects
which just pretend using .id).
In short: yes, the semantics
