Allen Wirfs-Brock wrote:
> I don't know,
>    'new Foo(args)'  create a mutable Foo object
>    'Foo(args)'           create an immutable Foo object
> isn't an idiom that we've had before

Relax "mutable" in the first comment and remove "object" from the second 
comment and we have relevant precedent:

   new Boolean(false) // create an extensible wrapper object
   Boolean(false) // unobservably return false or create a new false

   new Number(42) // create an extensible wrapper object
   Number(42) // unobservably return the argument or create a new 42

   new String('hi') // create an extensible wrapper object
   String('hi') // unobservably return argument or create new 'hi'

The point about value objects to attend to here: their identity based on 
frozen contents.

(Why are they objects? Because everything's an object except for the 
legacy primitives.)

The truthiness of new Boolean(false) is a problem for numeric value 
objects, which my int64/uint64 prototype addresses by including boolean 
test among the operators that can be defined for value objects.

There's no perfect precedent. Falsy 'new Boolean(false)' was rejected in 
ES1 standardization because it implied a conversion from object to 
boolean, which might happen more than once for a given sub-expression 
due to || and && being value-preserving.

What's more important given JS's legacy than precedent: serving users by 
considering use-cases for value objects.

The use-case for mutable structs and vectors is clear from today's 
objects used for points, homogenous coordinates, rectangles, shapes, etc.

The use-case for immutable structs and vectors is clear from SIMD work 
under way in TC39, in JS extensions, in Dart.

The propose to serve both use-cases by specifying that 'new T(x)' 
constructs a mutable value object while calling 'T(x)' makes an 
immutable one aims to avoid clumsy alternative static method factories 
or differently named wrappers.

Debatable, but showing class BigNum extends ValueObject doesn't decide 
the question. We are introducing new semantics, starting with by-value 
identity rather than by-reference, and extending to operators and 
literals. We can't do this just using ES6 'class' syntax as-is.

/be

Allen Wirfs-Brock wrote:
> I don't know,
>    'new Foo(args)'  create a mutable Foo object
>    'Foo(args)'           create an immutable Foo object
> isn't an idiom that we've had before

Relax "mutable" in the first comment and remove "object" from the second 
comment and we have relevant precedent:

```js
new Boolean(false) // create an extensible wrapper object
Boolean(false) // unobservably return false or create a new false

new Number(42) // create an extensible wrapper object
Number(42) // unobservably return the argument or create a new 42

new String('hi') // create an extensible wrapper object
String('hi') // unobservably return argument or create new 'hi'
```

The point about value objects to attend to here: their identity based on 
frozen contents.

(Why are they objects? Because everything's an object except for the 
legacy primitives.)

The truthiness of new Boolean(false) is a problem for numeric value 
objects, which my int64/uint64 prototype addresses by including boolean 
test among the operators that can be defined for value objects.

There's no perfect precedent. Falsy 'new Boolean(false)' was rejected in 
ES1 standardization because it implied a conversion from object to 
boolean, which might happen more than once for a given sub-expression 
due to || and && being value-preserving.

What's more important given JS's legacy than precedent: serving users by 
considering use-cases for value objects.

The use-case for mutable structs and vectors is clear from today's 
objects used for points, homogenous coordinates, rectangles, shapes, etc.

The use-case for immutable structs and vectors is clear from SIMD work 
under way in TC39, in JS extensions, in Dart.

The propose to serve both use-cases by specifying that 'new T(x)' 
constructs a mutable value object while calling 'T(x)' makes an 
immutable one aims to avoid clumsy alternative static method factories 
or differently named wrappers.

Debatable, but showing class BigNum extends ValueObject doesn't decide 
the question. We are introducing new semantics, starting with by-value 
identity rather than by-reference, and extending to operators and 
literals. We can't do this just using ES6 'class' syntax as-is.