Interfaces

Hi, 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170426/135c3df6/attachment.html>

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


>
> ```js
> // These are all checked via duck typing.
> interface IteratorResult {
>     // Properties
>     done;
>     value;
> }
>
> interface Iterator {
>     // required method
>     next();
>     // optional methods
>     throw?();
>     return?();
> }
>
> interface Iterable {
>     // Dynamic method name, checked via `typeof obj[Symbol.iterator] ===
> "function"`
>     [Symbol.iterator]();
> }
>
> // Interfaces may be anonymous and are themselves // new primitives const
> dynamic = interface {
>     foo();
> };
>
> assert(typeof dynamic === "interface");
>
> // Check if something implements an interface // Done via duck type
> checking via `[[Has]]` for // properties and `[[Get]]` for methods if
> (value implements dynamic) {
>     // ...
> }
>
> // Assert a class matches one or more interfaces class Foo implements
> Iterable, Iterator {
>     // ...
> }
> ```
>
> It's intentionally a subset of TypeScript's interfaces, mod new runtime
> behavior, and it specifically works structurally to work with existing duck
> typing mechanisms. (Browsers can already optimize this fairly well.)
> -----
>
> Isiah Meadows
> me at isiahmeadows.com
>
>
> On Wed, Apr 26, 2017 at 11:42 PM, doodad-js Admin <doodadjs at gmail.com>
> wrote:
> > Hi, 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.
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170427/b4af6da8/attachment.html>

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> 


-----Original Message-----
From: impinball at gmail.com <mailto:impinball at gmail.com>  [mailto: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 <mailto: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...

 


```js
// These are all checked via duck typing.
interface IteratorResult {
    // Properties
    done;
    value;
}

interface Iterator {
    // required method
    next();
    // optional methods
    throw?();
    return?();
}

interface Iterable {
    // Dynamic method name, checked via `typeof obj[Symbol.iterator] === "function"`
    [Symbol.iterator]();
}

// Interfaces may be anonymous and are themselves // new primitives const dynamic = interface {
    foo();
};

assert(typeof dynamic === "interface");

// Check if something implements an interface // Done via duck type checking via `[[Has]]` for // properties and `[[Get]]` for methods if (value implements dynamic) {
    // ...
}

// Assert a class matches one or more interfaces class Foo implements Iterable, Iterator {
    // ...
}
```

It's intentionally a subset of TypeScript's interfaces, mod new runtime behavior, and it specifically works structurally to work with existing duck typing mechanisms. (Browsers can already optimize this fairly well.)
-----

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


On Wed, Apr 26, 2017 at 11:42 PM, doodad-js Admin <doodadjs at gmail.com <mailto:doodadjs at gmail.com> > wrote:
> Hi, 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 <mailto:ljharb at gmail.com> ]
> Sent: Thursday, February 02, 2017 2:25 PM
> To: T.J. Crowder <tj.crowder at farsightsoftware.com <mailto:tj.crowder at farsightsoftware.com> >
> Cc: es-discuss at mozilla.org <mailto: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.
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org> 
> https://mail.mozilla.org/listinfo/es-discuss
>

 

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

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

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

> 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
>
>
>
> 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...
>
>
>
>
> ```js
> // These are all checked via duck typing.
> interface IteratorResult {
>     // Properties
>     done;
>     value;
> }
>
> interface Iterator {
>     // required method
>     next();
>     // optional methods
>     throw?();
>     return?();
> }
>
> interface Iterable {
>     // Dynamic method name, checked via `typeof obj[Symbol.iterator] ===
> "function"`
>     [Symbol.iterator]();
> }
>
> // Interfaces may be anonymous and are themselves // new primitives const
> dynamic = interface {
>     foo();
> };
>
> assert(typeof dynamic === "interface");
>
> // Check if something implements an interface // Done via duck type
> checking via `[[Has]]` for // properties and `[[Get]]` for methods if
> (value implements dynamic) {
>     // ...
> }
>
> // Assert a class matches one or more interfaces class Foo implements
> Iterable, Iterator {
>     // ...
> }
> ```
>
> It's intentionally a subset of TypeScript's interfaces, mod new runtime
> behavior, and it specifically works structurally to work with existing duck
> typing mechanisms. (Browsers can already optimize this fairly well.)
> -----
>
> Isiah Meadows
> me at isiahmeadows.com
>
>
> On Wed, Apr 26, 2017 at 11:42 PM, doodad-js Admin <doodadjs at gmail.com>
> wrote:
> > Hi, 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.
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170428/743c9811/attachment.html>

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>