Thanks for your attention, it’s appreciated....
1. Interfaces already have reserved real estate now (consider that `interface` and `implements` are both currently FutureReservedWords, meaning they're unusable in strict mode). Furthermore, the only way to efficiently implement them with decorators is through code generation. Yes, but the problem is we can’t reserve keywords for each type of class. Think of mixins and traits and others in the future. 2. Mixins don't have the same conceptual parts classes do, and if you ever hope to allow mixins to have constructor semantics (i.e. when classes using them are instantiated), the obvious `mixin.constructor.call(this)` is not possible without an engine assist. Construction/Destruction should be provided through a “Creatable” interface or something like that. Please look at how Doodad deals with that. 3. Keeping it purely syntactic allows engines to make optimizations they couldn't do otherwise, since they can just lower the optimizations into the bytecode they generate rather than relying on inline caching. For that part, you are better placed than me because I have no idea how the engine optimizes things. Doodad relies on “Class extenders”, making it dynamic and extensible. From: [email protected] [mailto:[email protected]] On Behalf Of Isiah Meadows Sent: Friday, April 28, 2017 6:01 PM To: doodad-js Admin <[email protected]> Cc: [email protected] Subject: Re: Interfaces If we're going to have interfaces and mixins natively within the language, they should be full syntactic first-class citizens, so the engine can optimize them far more efficiently. In addition, decorators for that kind of usage are a bad idea IMHO, because of a few reasons: 1. Interfaces already have reserved real estate now (consider that `interface` and `implements` are both currently FutureReservedWords, meaning they're unusable in strict mode). Furthermore, the only way to efficiently implement them with decorators is through code generation. 2. Mixins don't have the same conceptual parts classes do, and if you ever hope to allow mixins to have constructor semantics (i.e. when classes using them are instantiated), the obvious `mixin.constructor.call(this)` is not possible without an engine assist. 3. Keeping it purely syntactic allows engines to make optimizations they couldn't do otherwise, since they can just lower the optimizations into the bytecode they generate rather than relying on inline caching. ----- Isiah Meadows [email protected] <mailto:[email protected]> On Fri, Apr 28, 2017 at 7:03 AM, doodad-js Admin <[email protected] <mailto:[email protected]> > wrote: I was more thinking of something like: @interface class Name { } @mixin class Name { } ...
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
