Interfaces

# doodad-js Admin (7 years ago)

I’m starting a new thread from the bottom message.

I did a great work to provide OOP in Javascript, but nobody seems to care, and some even given me bad intentions. But I continue to persist...

My framework already provides a solution on the user space. All that remains is to port it to a more lower level, in combination to existing proposals like public class fields, private fields, class and property decorators, ... To just name a few.

(I’m French, so I’m sorry if my English is not accurate)

From: Jordan Harband [mailto:ljharb at gmail.com] Sent: Thursday, February 02, 2017 2:25 PM To: T.J. Crowder <tj.crowder at farsightsoftware.com>

Cc: es-discuss at mozilla.org Subject: Re: Short Comparing proposal

It seems like a far more useful proposal (although much larger in scope) would be some concept of interface comparison, and then you could see if object matches "an interface that has an a and b property", but also if object is "arraylike", or "iterable", or a "thenable", etc.

# Isiah Meadows (7 years ago)

They could be. I didn't initially include it, but that does logically follow from it.


Isiah Meadows me at isiahmeadows.com

On Thu, Apr 27, 2017 at 7:05 AM, doodad-js Admin <doodadjs at gmail.com> wrote:

I like it. Are interfaces extendable? I mean something like...

interface CustomerSummary { // ... }

interface CustomerDetails extends CustomerSummary { // ... }

Claude Petit doodadjs at gmail.com

-----Original Message----- From: impinball at gmail.com [mailto:impinball at gmail.com] On Behalf Of Isiah Meadows Sent: Thursday, April 27, 2017 1:23 AM To: doodad-js Admin <doodadjs at gmail.com> Subject: Re: Interfaces

I'm thinking, maybe if someone could combine this with a decent mixin proposal, this would work well.

Here's my idea for interface checking:

Note: this != mixin. I probably could've worded this better...

# doodad-js Admin (7 years ago)

I was more thinking of something like:

@interface

class Name {

}

@mixin

class Name {

}

...

From: impinball at gmail.com [mailto:impinball at gmail.com] On Behalf Of Isiah Meadows Sent: Thursday, April 27, 2017 9:32 AM To: doodad-js Admin <doodadjs at gmail.com>

Cc: es-discuss at mozilla.org Subject: Re: Interfaces

They could be. I didn't initially include it, but that does logically follow from it.


Isiah Meadows me at isiahmeadows.com <mailto:me at isiahmeadows.com>

On Thu, Apr 27, 2017 at 7:05 AM, doodad-js Admin <doodadjs at gmail.com <mailto:doodadjs at gmail.com> > wrote:

I like it. Are interfaces extendable? I mean something like...

interface CustomerSummary { // ... }

interface CustomerDetails extends CustomerSummary { // ... }

Claude Petit doodadjs at gmail.com <mailto:doodadjs at gmail.com>

# Isiah Meadows (7 years ago)

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

# doodad-js Admin (7 years ago)

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.

  1. 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.

  1. 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 {

}

...