On Jul 15, 2013, at 8:15 AM, Mark S. Miller <erights at google.com> wrote:
> 
> No wrapping object type -- those are legacy, to be avoided. See http://wiki.ecmascript.org/doku.php?id=strawman:value_objects. The main thing is value not reference semantics.
> 
> On that page: "It’s forwards-compatible with future mechanisms for user-defined value objects." How can we be confident of this? I would like to be.

That's a concern I have as well -- i'm not 100% sold on user-defined value objects, but i think i'd prefer that we get those done before bolting on [u]int64 and hoping that they're forwards compatible.  I don't want to deal with any "we can't do x due to uint64" style problems.

--Oliver

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130715/664cfaa0/attachment.html>

On Jul 15, 2013, at 8:15 AM, Mark S. Miller <erights at google.com> wrote:
> 
>> No wrapping object type -- those are legacy, to be avoided. See http://wiki.ecmascript.org/doku.php?id=strawman:value_objects. The main thing is value not reference semantics.
> 
> On that page: "It’s forwards-compatible with future mechanisms for user-defined value objects." How can we be confident of this? I would like to be.

That's a concern I have as well -- i'm not 100% sold on user-defined value objects, but i think i'd prefer that we get those done before bolting on [u]int64 and hoping that they're forwards compatible.  I don't want to deal with any "we can't do x due to uint64" style problems.

On Jul 15, 2013, at 8:15 AM, Mark S. Miller <erights at google.com> wrote:
> 
>> No wrapping object type -- those are legacy, to be avoided. See http://wiki.ecmascript.org/doku.php?id=strawman:value_objects. The main thing is value not reference semantics.
> 
> On that page: "It’s forwards-compatible with future mechanisms for user-defined value objects." How can we be confident of this? I would like to be.

That's a concern I have as well -- i'm not 100% sold