Interfaces

[Isiah Meadows]

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>