new instantiation design alternatives

Kevin Smith zenparsing at gmail.com
Sun Sep 14 20:48:49 PDT 2014


>
>
> perhaps:
>
> `constructor{a: x, b: y), [a1,a2,a3,...arest], c ) : super(arguments[0],
> arguments[1]) {}`
>
> but that means that the special header form must allow arbitrary
> expressions.  Are those expression in the parameter scope of the body scope.
>

Yes and yes.


>
> Most importantly, a single constrained expression isn't expressive enough.
>  The problem, is that a subclass constructor may need to perform arbitrary
> compelx computations before super newing the its base constructor.  For
> example, consider a TypeArray subclass constructor that filters various
> collections passed to to the derived  constructor to produce a simple list
> iterator that it passed to the  base constructor.
>

Would this work?

    class C extends B {
        constructor(a, b, c) : super(...gimmeSomeComplexSuperArgsYo(a, b,
c)) {
            // ...
        }
    }

Or using static helper methods, if you prefer:

    class C extends B {
        constructor(a, b, c) : super(...this.gimmeSomeSuperArgsYo(a, b, c))
{
            // ...
        }
        static gimmeSomeSuperArgsYo(a, b, c) {
            // ...
        }
    }

If being (painfully) explicit is desired, then you could require the "new"
in there:

    class C extends B {
        constructor() : new super() { }
    }

It seems to me that with the proposed design we're going to have to branch
on "new^" continually:  if we don't, then the function will always fail if
[Call]'ed and it contains a this-setter.

With the class create expression approach, that branch is taken care of
automatically.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140914/61746dc6/attachment-0001.html>


More information about the es-discuss mailing list