is it possible to have private state AND sub-classability? about native-promise-only

[javascripter]

looking at davy, it looks like it directly accesses this.vaule and this.deferreds so it does not have private states.

[javascripter]

However I think it is possible to have immutability without a private state using Object.defineProperty.

var obj = {};
Object.defineProperty(obj, 'prop', {
    writable: false,
    enumerable: false,
    configurable: false,
    value: 123
});
console.log(obj.prop); // 123
obj.prop = 1;
console.log(obj.prop); // 123
delete obj.prop;
console.log(obj.prop); // 123

Therefore if my understanding is correct by doing this:

function Promise() {
  var somePrivateState;
  Object.defineProperty(this, '_then', {
    writable: false, configurable: false, enumerable: false,
    value: function() {
      // actual then function using somePrivateState
    }
  };
}
Promise.prototype.then = function () {
  return this._then.apply(this, arguments);
};

You will not have external mutations of promises. This would seem to be a better trade-off.

[getify]

Yes, that's conceptually kinda similar to what I'm already doing, except you put a public then on the Promise.prototype to point to internal state, whereas I just had it internal already. Mostly the same end result.

The difference is you have a public prototype then which mine only has then on the instance. Mine could easily do that, but the question is, how would someone do sub-classability (both in ES5 and ES6) with this pattern? I believe the problem will be sub-classes will also not be able to access the private state, which one would almost certainly expect.

Let's explore that.

In ES5:

function CustomPromise(fn) {
   var morePrivateState = { .. };
   Promise.call(this,fn);
   Object.defineProperty(this, "_customThen", {
      writable: false, configurable: false, enumerable: false,
      value: function() {
         // other custom stuff with `morePrivateState`
         // this._then.apply(this, arguments);
         // the problem is I have no access to `somePrivateState` from parent, so I may be quite
         // limited in what I can do here.
         // At best, this is limited (and potentially subtly so) sub-classing.
      }
   );
}

CustomPromise.prototype = Object.create(Promise.prototype);

CustomPromise.prototype.customThen = function() {
   return this._customThen.apply(this,arguments);
};

var myPromise = new CustomPromise(myResolver);

myPromise.customThen(success,failure);

// ...

In ES6:

class CustomPromise extends Promise {
   CustomPromise(fn) {
      var morePrivateState = { .. };
      super(fn);
      Object.defineProperty(this, "_customThen", {
         writable: false, configurable: false, enumerable: false,
         value: function() {
            // other custom stuff with `morePrivateState`
            // this._then.apply(this, arguments);
            // the problem is I have no access to `somePrivateState` from parent, so I may be quite
            // limited in what I can do here.
            // At best, this is limited (and potentially subtly so) sub-classing.
         }
      );
   }
   customThen() {
      return this._customThen.apply(this,arguments);
   }
}

var myPromise = new CustomPromise(myResolver);

myPromise.customThen(success,failure);

// ...

In both ES5 and ES6 syntaxes, it comes down to having the state partitioned between Promise (parent) and CustomPromise (child). If customThen(..) or _customThen(..) needed to update the pending state, or the value, or something... they cannot.

They are limited to only being able to track and modify their own child state, but they would probably need to be modifying the "inherited" parent-private state, which they cannot.

In practice, I believe this would basically devolve to fully re-specifying behavior on the CustomPromise.prototype and fully re-specifying all state behavior in the CustomPromise constructor closure.

The other option from the above code is to avoid calling the parent constructor, which thus avoids creating the parent private state AND it avoids creating any _then to use, which means you would end up re-specifying the internal state AND the implementation of _then down on the child, which is again basically making the sub-classing almost entirely moot.

In other words, in practice, there would be little to no benefit to being able to sub-class. You can, but it doesn't get you anything substantial.

Make sense?

[getify]

I feel pretty confident that from the polyfill standpoint, this is a trade-off, and not one I'm willing to make. Promise immutability is more important than sub-classing.

The only other way to keep state private would be to use a WeakMap which is not practically polyfillable (its performance would be unacceptable). That's great for reference implementations, but unacceptable for a polyfill.