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.
Item 2 is important but hard to get right in the face of mutable objects
and prototype chains.
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.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
