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

Tristan Zajonc wrote:
> 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.