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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
