Interfaces

[doodad-js Admin]

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: impinball at gmail.com [mailto:impinball at gmail.com] On Behalf Of Isiah Meadows
Sent: Friday, April 28, 2017 6:01 PM
To: doodad-js Admin <doodadjs at gmail.com>
Cc: es-discuss at mozilla.org
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
me at isiahmeadows.com <mailto:me at isiahmeadows.com> 

 

On Fri, Apr 28, 2017 at 7:03 AM, doodad-js Admin <doodadjs at gmail.com <mailto:doodadjs at gmail.com> > wrote:

I was more thinking of something like:

 

@interface

class Name {

}

 

@mixin

class Name {

}

 

...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170428/321667db/attachment-0001.html>