Open juandopazo opened 11 years ago
It'll eventually be possible, but currently engines haven't really progressed so far to make host objects subclassable.
Is there anything the specs can say to make this more possible? Or do the specs already say that they should be subclassable, and implementations just haven't caught up?
I think implementing @@create hasn't happened yet and will take a long time. Once that's done there might be some further work spec-wise, but that's far away.
I don't think @@create
is necessary for subclassability, except in very specific exotic object cases... After all, normal user-land promises are subclassable and don't have access to @@create
.
@domenic Promises have hidden internal state, do they not? If so, to do sub classing the instance must be created with the correct internal structure.
Oh right! I didn't consider it is the same as any other host object. I guess we can use __proto__
in those engines that support promises, but it does complicate things a bit if we want to use polyfills.
@arv right, they certainly do, but currently those engines create this internal state inside the non-stratified constructor (at least, that's what it seems like reading http://src.chromium.org/viewvc/blink/trunk/Source/bindings/v8/custom/V8PromiseCustom.cpp?pathrev=153560#1284). Later the allocation and initialization steps will be stratified, but I don't see why you can't derive from the current version and call Promise.apply(this, arguments)
to set up the internal structure, plus initialize the promise, in one single un-stratified step.
@domenic That would not be consistent with ES6. ES6 have [[Call]] throw if the internal data field is not present. See for example http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.14.1.1 , the 3rd step.
If map does not have a [[MapData]] internal data property, then throw a TypeError exception.
If we allowed Promise.apply(this, arguments)
that would be future hostile.
Ah, I see now. Thanks. :(
Please correct me if I'm wrong but does this mean that in the foreseeable future native (e.g: browser) Promise implementations will not support subclassing?
I guess I will just have to feature detect and replace these limited implementations by a shim?
var useShim = typeof Promise === 'undefined' || !(function() {
// Also ensure that Promise class can be properly extended
var objectCreate = Object.create || function(proto) { function F() {} F.prototype = proto; return new F(); };
function SubClass(fn) { Promise.call(this, fn); }
SubClass.prototype = objectCreate(Promise.prototype);
SubClass.prototype.constructor = SubClass;
try { var sub = new SubClass(function() {}); sub.then(); return true; } catch (e) {}
}());
I just tried the implementation in Chromium 30 and Firefox Nightly and both throw an error when trying to use prototype delegation with them.
Chromium throws
TypeError: DOM object constructor cannot be called as a function
when trying to usePromise.call
.Firefox throws when calling
then
in the subclassed promise:TypeError: 'then' called on an object that does not implement interface Promise.
Is this by design?
__proto__
works but... you know.