David-Sarah Hopwood david-sarah at
Wed Jun 10 07:25:50 PDT 2009

Sam Ruby wrote:
> Independent of any discussion of predefined numeric types, I believe
> that there is a class of performance critical applications that could
> benefit from an introduction of "structs" into ES.  Additionally, such
> an addition could make ES more attractive as a compilation target (I
> say while glancing meaningfully in the direction of Allen).

I agree.

> Since implementations will be free to (but not required to) copy the
> value instead of the reference, it is important that the triple equals
> operator compares the values for struct types.

Yes. === should behave like SameValue, with NaN !== NaN and 0 === -0 as
the only exceptions. SameValue should behave like Henry Baker's 'egal'.

> Given the above, the answer to the below is less clear:
>   foo = {}
>   foo[Rational(4,2)]='a'
>   foo[Rational(2,1)]='b'
>   foo[2]='c'
>   foo[Rational(2,1)] ==> 'b' ???
>   foo[Rational(4,2)] ==> 'a' ???

The property position of the [_] operator is coerced by ToString in ES3/5.
For struct types to behave differently would be irregular. (Even if this
coercion was not a good idea in the first place, creating exceptions to
it does not really help.)

So *if* ToString(Rational(4,2)) === ToString(Rational(2,1)) === '2', then
these references would all alias the '2' property of foo.

> The motivation for the above is the question of whether or not there
> will be the possibility of any user visible cohorts.

I'm with MarkM on this -- it is impossible to prevent a user-defined
type from having cohorts, but desirable not to standardize any type that

> Double dispatch also provides an opportunity to mitigate the usability
> problem that Brendan often laments.  While the Rational package can
> provide a default implementation for a set of operator overloads (I'll
> note that every double precision binary floating number has an exact
> representation in terms of a rational number, something that is not
> true in reverse), users that desire different behavior can simply
> replace these operators.  This could even be done globally (a big red
> switch, as Brendan seems to prefer).

It should be done within a specified lexical scope. I'll post a proposal
for that at some point (not soon since I'm concentrating on ES5 and
Jacaranda at the moment).

David-Sarah Hopwood  ⚥

More information about the es-discuss mailing list