Domenic Denicola wrote:
> From: Rick Waldron [waldron.rick at gmail.com]
>
>> Regardless, I support your claim. It's not that library authors use this pattern in all constructor definitions, all the time—it's a pattern used by responsible authors when creating constructors to ensure user code will just work, whether invoked
>   with or without "new".
>
> Indeed. I actually first thought of it in the context of how we want the DOM to work, now that there's a push for actual constructors. I thought the DOM types should probably work like the built-in types do (viz. `Object`, `Array`, `Function`, and `RegExp`, albeit not `Date` as Claude points out). And if were to specify something about DOM constructors generally, we should make sure it follows ES6 class syntax.
>
>> Back to Domenic's original post... I would also like this to be the default semantics for class, but wonder if that will bite program code that assumes (incorrectly, if it doesn't abide strict mode) these have th
e same invocation semantics:
>
> I see what you're saying, but I think classes already have minor tweaks (e.g. default super-invocation and the existence of super) that one more wouldn't hurt. At least, that was my logic :P

Going by this logic, one can argue for other tweaks instead - for example - I repeat myself - to fix the super vs. new disrepancy by introducing saner sematics for new Class (calling F.prorotype.constructor instead of F, thus doing (more or less, with special non-typeof-object exceptional case) `F[@@create].constructor(...args)` instead of `F.call(F[@@create], ...args)` and be aligned with super). And one can easily include [[Call]] into it by making F itself being compiled into `return new F(...args)` (and include the working code itself in the constructor).

Herby

P.S.: In fact, I would say, for future, the new semantics (F[@@create].constructor(...args)) should be the default for any object usable with new, since it is totally generic (no need for F.c
all to work; just having [@@create] and produce thing with .constructor) and leaving the old one for legacy constructor functions.

Domenic Denicola wrote:

> I see what you're saying, but I think classes already have minor tweaks (e.g. default super-invocation and the existence of super) that one more wouldn't hurt. At least, that was my logic :P

Going by this logic, one can argue for other tweaks instead - for example - I repeat myself - to fix the super vs. new disrepancy by introducing saner sematics for new Class (calling F.prorotype.constructor instead of F, thus doing (more or less, with special non-typeof-object exceptional case) `F[@@create].constructor(...args)` instead of `F.call(F[@@create], ...args)` and be aligned with super). And one can easily include [[Call]] into it by making F itself being compiled into `return new F(...args)` (and include the working code itself in the constructor).

P.S.: In fact, I would say, for future, the new semantics (`F[@@create].constructor(...args)`) should be the default for any object usable with new, since it is totally generic (no need for F.c
all to work; just having [@@create] and produce thing with .constructor) and leaving the old one for legacy constructor functions.