Promise() vs. new Promise()

Andrea Giammarchi andrea.giammarchi at gmail.com
Thu Aug 21 02:03:19 PDT 2014


Agreed, and not only Promise.

AFAIK there is no way to detect if a generic constructor is a typeof
'class' or just a function, then invokable through a well known, commonly
used pattern as `Generic.call(obj, p1, p2)` is when it comes to generics
initializations.

This is also a precedent that suggest `Object.create(Generic.prototype)` is
useless when the `Generic` is ES6 class due inability to initialize it
later on: a very "bad news" for prototypal inheritance.

Accordingly, interoperability with old code (the "one JS" myth) is
compromised and prototypal inheritance won't be "fully portable" with
user-land classes.

Latter is not necessarily unexpected since we know other cases that could
fail, i.e.

```js
var a = Object.create(Array.prototype);
Array.call(a, 1, 2, 3);
a; // still empty

Array(1, 2, 3); // [1,2,3]
```

but interoperability with user land classes, the inability to initialize an
object through one or more constructor composing behaviors, and the
inability to emulate `new` does not make it look like a wise choice.

On the other hand, what is the advantage of knowing that `new` was used, if
not for some syntax parser or JIT sake, if any?

Why anyone would like to be sure `new` was used instead of `Object.create`
and why the former should keep failing with native and now with classes too?

Just curious to know who or what will end up benefiting this choice.

Thanks in advance for clarifications

Best Regards






On Thu, Aug 21, 2014 at 8:22 AM, Salvador de la Puente González <
salva at unoyunodiez.com> wrote:

> The only problem I see here is you can not emulate completely `new` with
> ES. Why Promise add some internal slots when called with new and it does
> not make the same when writing `var p = Object.create(Promise.prototype);
> Promise.call(p, fn);`?
>
>
> On Thu, Aug 21, 2014 at 5:18 AM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> To this I'd like to add that in ES6 you don't need to explicitly invoke
>> inherited class constructor but rather use `super`
>>
>> True is that this `new` story makes Mixins like constructors more
>> difficult to use as classes becuase these cannot be invoked via `.call` or
>> `.apply` directly and requires a very boring `init()` like method.
>>
>> Although there's nothing for mixins or their initialization in ES6 so
>> it's OKish ...
>>
>> Last, but not least, since you use instanceof, I'd like to underline in
>> ES5 capable browser you have another pattern.
>>
>> ```js
>> function SelfInstance() {'use strict';
>>   return this || new SelfInstance;
>> }
>> ```
>>
>> no need to use the `instanceof` check when `this` could be undefined ^_^
>>
>> Regards
>>
>>
>>
>>
>> On Wed, Aug 20, 2014 at 5:55 PM, Alex Kocharin <alex at kocharin.ru> wrote:
>>
>>>
>>> 20.08.2014, 19:18, "Claude Pache" <claude.pache at gmail.com>:
>>> > Le 20 août 2014 à 16:56, Alex Kocharin <alex at kocharin.ru> a écrit :
>>> >>  But... why?
>>> >>
>>> >>  I mean, every constructor can determine if it is called without
>>> `new` (that "this instanceof" check on top of every other constructor). So
>>> `new` keyword can really be removed from everywhere except in constructors
>>> themselves.
>>> >>
>>> >>  Using `new` does create issues. For example, you can't write "new
>>> require('something').Constructor(blah)", and I don't even remember how to
>>> put brackets right.
>>> >>
>>> >>  Why make people use it?
>>> >
>>> > According to http://esdiscuss.org/notes/2013-07-25 (search for
>>> "anti-pattern"), allowing constructors without `new` would break
>>> subclassing.
>>>
>>> Still doesn't make much sense... This pattern (this instanceof ...)
>>> breaks another pattern (BaseClass.call(this)). Why first one is deprecated,
>>> not the second one?
>>>
>>> I mean, I was able to subclass such a class with prototype injection
>>> without any issues, and it feels more natural in javascript after all.
>>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140821/62160c01/attachment-0001.html>


More information about the es-discuss mailing list