Thanks for this reply.
> Filip Pizlo <mailto:fpizlo at apple.com>
> September 8, 2013 1:56 PM
> We have two choices:
>
> A) Reject the notion that 'obj' appearing once in the original source 
> results in multiple calls to some hook on 'obj' (valueOf, toBoolean, 
> whatever).
> B) Allow multiple calls along with all that it entails.
>
> I like the idea of B because as weird as it is, the pros outweigh the 
> cons, in my own accounting.  I hope I didn't miss any pros or cons.

I mentioned another in private email to you, while noting that it's too 
narrow: a value object class would be able to define a static "zero" 
value (observably immutable and with copy not reference semantics, as 
for all value object instances). This would be bit-compared by ToBoolean.

Problem is it doesn't support signed zero (IEEE 754r decimal has them, 
just like 754 binary floating point). More general (not just for numeric 
value objects) problem: value objects might need multiply falsy values.

A grandiose idea, inspired by JMatch 
(http://www.cs.cornell.edu/Projects/jmatch/). Instead of an arbitrary 
hook, support a general linear-algebraic projection function 
(http://en.wikipedia.org/wiki/Projection_%28linear_algebra%29) by which 
the JS VM can verify that the ToBoolean hook is idempotent (and even 
optimize accordingly if we want to allow that). I doubt this could be 
both expressive and efficient enough but I thought I'd throw it out here!

[pro vs. con analysis, with which I agree, deleted. /be]

> Note that I didn't include compatibility in the Con list - maybe I'm 
> wrong but it feels like there ought to be a way of adding an API to 
> register a toBoolean hook such that if you don't call the hook you're 
> *guaranteed* to get the old behavior.  But this does imply that we use 
> a new hook (something like a toBoolean method) rather than saying that 
> ToBoolean calls valueOf or toString.

Agreed. My value-objects strawman reserves boolean-test as a hook 
available only for novel classes of objects, solving the fairly pressing 
numeric/scicomp/SIMD/etc. use-cases without letting other classes of 
objects sprout such hair.

> So, sorry to push on this ancient decision - but it really feels like 
> we could get a lot of win from reconsidering it.

No need to apologize -- thanks again for the followup!

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130908/e6beead5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130908/e6beead5/attachment-0001.jpg>

Thanks for this reply.

Filip Pizlo <mailto:fpizlo at apple.com> September 8, 2013 1:56 PM
> We have two choices:
>
> A) Reject the notion that 'obj' appearing once in the original source results in multiple calls to some hook on 'obj' (valueOf, toBoolean, whatever).
> B) Allow multiple calls along with all that it entails.
>
> I like the idea of B because as weird as it is, the pros outweigh the 
> cons, in my own accounting.  I hope I didn't miss any pros or cons.

I mentioned another in private email to you, while noting that it's too 
narrow: a value object class would be able to define a static "zero" 
value (observably immutable and with copy not reference semantics, as 
for all value object instances). This would be bit-compared by ToBoolean.

Problem is it doesn't support signed zero (IEEE 754r decimal has them, 
just like 754 binary floating point). More general (not just for numeric 
value objects) problem: value objects might need multiply falsy values.

A grandiose idea, inspired by [JMatch](http://www.cs.cornell.edu/Projects/jmatch/). Instead of an arbitrary 
hook, support a general linear-algebraic [projection function](http://en.wikipedia.org/wiki/Projection_%28linear_algebra%29) by which 
the JS VM can verify that the ToBoolean hook is idempotent (and even 
optimize accordingly if we want to allow that). I doubt this could be 
both expressive and efficient enough but I thought I'd throw it out here!

[pro vs. con analysis, with which I agree, deleted. /be]

> Note that I didn't include compatibility in the Con list - maybe I'm 
> wrong but it feels like there ought to be a way of adding an API to 
> register a toBoolean hook such that if you don't call the hook you're 
> *guaranteed* to get the old behavior.  But this does imply that we use 
> a new hook (something like a toBoolean method) rather than saying that 
> ToBoolean calls valueOf or toString.

Agreed. My value-objects strawman reserves boolean-test as a hook 
available only for novel classes of objects, solving the fairly pressing 
numeric/scicomp/SIMD/etc. use-cases without letting other classes of 
objects sprout such hair.

> So, sorry to push on this ancient decision - but it really feels like 
> we could get a lot of win from reconsidering it.

No need to apologize -- thanks again for the followup!