Andrea Giammarchi: > They want magic most of time anyway :-) If the other trend of moving away from monolithic frameworks to composable libraries is any indicator, magic is on it’s way out as well. Good riddance.
Glen Huang:
> Since we required methods defined within class definitions non-enumerable by
> default, I think we should discourage people to do things like:
>
> class Foo { … }
> bar = () => {}
> Foo.prototype.bar = bar;
> Foo.prototype.addtionalMethod = () => {}
Why? It’s _the_ simplest approach for 99 use-cases, disregarding the `super`
issue for a sec. Append to your prototype with regular code, then inherit.
Wrap, bind, curry functions to your heart’s content. Simple.
Take it too far and you end up with something akin to Ruby (and its origins):
metaclasses of metaclasses, multiple inheritance, prepended modules and
appended classes.
Leon Arnott:
> So... I think this scenario would be better served if ES7 had shorthands for
> non-(enumerability|writability|configurability) added to the object literal
> syntax, as some in the past have postulated - and a method for copying
> non-enumerable (and also symbol-keyed) properties was available.
Now that’s a better generic proposal. Something for imperative use as well and
everything’s covered.
A.
On Feb 20, 2015, at 13:00, Andrea Giammarchi <[email protected]>
wrote:
> They want magic most of time anyway :-)
>
> I wasn't saying enumerable and others are keywords aren't a bad idea, I'm say
> when you import to class you would probably expect non enumerable anyway, and
> too verbose class declarations aren't that good-looking.
>
> Hope you got my point.
>
> Regards
>
> On Fri, Feb 20, 2015 at 10:28 AM, Glen Huang <[email protected]> wrote:
> Thanks for the examples. But I wonder why beat around the bush and not let
> developers express exactly what they want?
>
> > On Feb 20, 2015, at 5:51 PM, Leon Arnott <[email protected]> wrote:
> >
> > Ah, right, my apologies for misreading.
> >
> > So... I think this scenario would be better served if ES7 had shorthands
> > for non-(enumerability|writability|configurability) added to the object
> > literal syntax, as some in the past have postulated - and a method for
> > copying non-enumerable (and also symbol-keyed) properties was available.
> >
> > ```
> > class Foo { ... }
> >
> > Object.copyOwnProperties(Foo.prototype, {
> > noenum bar, /* Assigns 'bar' to the object, making it non-enumerable and
> > non-writable */
> > noenum additionalMethod() { ... },
> > noenum *[Symbol.iterator]() { ... },
> > });
> > ```
> >
> > Object.assign vs Object.copyOwnProperties may seem awkward, but it's
> > arguably comparable to the Object.keys/Object.getOwnPropertyNames dichotomy
> > - one for the common case, one for the thorough case. (I'm aware that
> > Object.getOwnPropertyNames is deprecated in favour of Reflect.ownKeys,
> > though.)
> >
> > In cases where all the methods are new, this could be "simplified" to:
> >
> > ```
> > Object.copyOwnProperties(Foo.prototype, class {
> > baz() { ... }
> > *[Symbol.iterator]() { ... }
> > }.prototype);
> > ```
> >
> > Of course, while writing all this I just thought of yet another problem:
> > there's no way to copy accessors using this hypothetical
> > Object.copyOwnProperties.
> >
> > Maybe there should also be a specially tuned method on Function:
> >
> > ```
> > Function.assign(Foo, class {
> > qux() {...}
> > *[Symbol.iterator] {...}
> > get flib() {...}
> > static flab() {...}
> > });
> > ```
> >
> > And let copyOwnProperties be used for assigning existing methods.
> >
> > Classes are kind of an awkward data structure, I must say. :|
> >
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
