Proposal for new floating point and integer data types
tristan at senseplatform.com
Tue Oct 29 11:34:49 PDT 2013
One clarification on the value objects proposal... The JSConf slides say
that immutability is implemented as an implicit Object.freeze(this) on
return in the constructor. Is this meant as shorthand for a deep freeze?
On Tue, Oct 29, 2013 at 11:13 AM, Tristan Zajonc
<tristan at senseplatform.com>wrote:
> On Tue, Oct 29, 2013 at 10:08 AM, Brendan Eich <brendan at mozilla.com>
> Tristan Zajonc wrote:
>>> It's true that in JS today, comparing an object to a non-object,
>>> valueOf or toString on the object can be used to make == results
>>> However, I'm proposing value objects with declarative syntax to
>>> solve several problems:
>>> 1. Backward compatibility, so == uses cannot change unexpectedly
>>> on extant code, or grow performance hair in existing engines
>>> facing existing code.
>>> 2. Solve the cross-frame problem where loading the same value
>>> class declaration results in the same typeof and other results for
>>> operations on values instantiated from equivalent declarations
>>> (details still being worked out).
>>> 3. Facilitate functional programming, both for user benefit and
>>> for engines, which can better optimize based on immutable values
>>> (including stack allocation).
>>> On 3, I think mutability is a required option for matrix libraries.
>>> While immutable matrix APIs are interesting, I do not believe anybody has
>>> successfully implemented a flexible high performance immutable matrix
>>> library in any language. I think the key user demand is porting basic
>>> MATLAB like numeric code to JS, which wouldn't be possible with an
>>> immutable library.
>> The Haskell folks will disagree with you, but I'll let them speak for
> My point here is only that I don't think JS should adjudicate this debate
> in the context of operators. It seems like this discussion should happen
> if a Matrix type is added to the core of JS. Having operators would
> encourage the development of cow paths.
>> Item 2 is important but hard to get right in the face of mutable objects
>> and prototype chains.
> I don't understand this issue well enough to comment.
>> Can value objects / immutability be separated from operator overloading?
>> Almost certainly. I'm starting with value objects because in design,
>> leaving things out (without necessarily being future-hostile to extension)
>> is generally better than trying to do include too much.
>> The value class syntax (operator multimethods) that I showed at JSConf.eu
>> could easily be class syntax, as you surmised.
> Got it. I'm a fan of the syntax and dispatch mechanism.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss