Are DOM Promises intended to be inherited from in user code? #71

Activity

1. annevk commented on Jul 18, 2013

   

   annevk

   on Jul 18, 2013

   Collaborator

   More actions

   It'll eventually be possible, but currently engines haven't really progressed so far to make host objects subclassable.
2. domenic commented on Jul 18, 2013

   

   domenic

   on Jul 18, 2013

   Collaborator

   More actions

   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?
3. annevk commented on Jul 18, 2013

   

   annevk

   on Jul 18, 2013

   Collaborator

   More actions

   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.
4. domenic commented on Jul 18, 2013

   

   domenic

   on Jul 18, 2013

   Collaborator

   More actions

   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.
5. arv commented on Jul 18, 2013

   

   arv

   on Jul 18, 2013

   Collaborator

   More actions

   @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.
6. juandopazo commented on Jul 18, 2013

   

   juandopazo

   on Jul 18, 2013

   Author

   More actions

   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.
7. domenic commented on Jul 18, 2013

   

   domenic

   on Jul 18, 2013

   Collaborator

   More actions

   @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.
8. arv commented on Jul 18, 2013

   

   arv

   on Jul 18, 2013

   Collaborator

   More actions

   @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.
9. domenic commented on Jul 18, 2013

   

   domenic

   on Jul 18, 2013

   Collaborator

   More actions

   Ah, I see now. Thanks. :(
10. difosfor commented on Jul 8, 2014

    

    difosfor

    on Jul 8, 2014

    More actions

    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) {}
    }());