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 <[email protected]>wrote: > On Tue, Oct 29, 2013 at 10:08 AM, Brendan Eich <[email protected]> > wrote: > > 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 >>> vary. >>> >>> 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 >> themselves. >> >> > 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. >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
