The new operator

Brendan Eich brendan at
Sun May 13 10:57:00 PDT 2012

Axel Rauschmayer wrote:
> Until, I’ve stuck to the simple rule: Always use `new` when 
> you want to create an instance. That avoids confusion when it comes to 
> functions such as String and Boolean: I like using them to coerce values.
User-defined constructors are often coded so that users must invoke via 
new. This may happen, therefore it does happen, and it won't go away. I 
don't know why you are treating as some slate-cleaning exercise, 
below ("Do we still need ..."). The answer by default is "yes".

> Given that value object constructors such as uint64 are currently 
> invoked without `new`, I’m wondering whether that rule changes:
> - Do we still need `new`? If we had class declarations, their 
> desugared versions could easily always create new instances, whether 
> invoked via `new` or as a function. The same holds for object 
> exemplars: Calling such an exemplar could “instantiate” it.

Protocols are fine and perhaps a new-free one will take over some years 
hence, but not soon.

> - Should there be alternate, possibly less confusing, ways of coercing 
> values? ToPrimitive() would certainly be nice to have.

An object may need to be coerced to a number of value types. How would 
ToPrimitive know which one to use? There may be a default, but not a 
unique target type.


More information about the es-discuss mailing list