new instantiation design alternatives

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Sep 17 12:19:01 PDT 2014


On Sep 17, 2014, at 10:50 AM, Erik Arvidsson wrote:

> I still feel like Kevin's point has not yet been resolved. How can we make this work with today's patterns?
> 
> import {C} from './C.js';
> 
> function D() {
>   C.call(this);
> }
> D.prototype = {
>   __proto__: C.prototype,
>   constructor: D,
>   ...
> }
> 
> Now assume that C.js initially used the ES5 pattern above and it was later changed to use class syntax using `this =`.
> 
> class C extends B {
>   constructor() {
>     this = new super();
>   }
> }
> 
> Since we are doing a C[[Call]] we will get a runtime error here.

Of course, if you don't need to change anything if you want to keep using your pre-ES6 class model.

But, since C is existing ES5 code, the appropriate way to update using ES6 features and maintain compatability with ES5 level subclasses would be::

class C extends B {
  constructor() {
    if (this^) {
        // invoked as: new C() or new super() from ES6 level code
        this  = objToInitialize = new super();
    } else {
        //legacy compat with ES5-level subclasses that do C.call invocation
       assert(typeof this == "object");  //if this is undefined then C must have been invoke: as:C() rather than as: C.call(this); we may or may not need to support that case.
       objToInitialize = this;
    }
    // initialization logic applied to objToInitialize
    //...
    //note, explicit return is not required
  }
}


You have to worry about this sort of stuff when evolving a library or framework..  New application level code shouldn't have to deal with it.

Allen




More information about the es-discuss mailing list