A tempest in a teapot. We can have better APIs that look nice for this
use-case. Develop some!
But let's not rush them into ES6, or invent custom syntax where API is
enough.
If someone does fast and good work, there's still time for ES6, or 7
(doesn't matter as much as the quality of the work; browsers are
prototyping parts of both).
/be
Dmitry Soshnikov wrote:
On Jun 11, 2013, at 8:07 PM, Andrea Giammarchi wrote:
if it's about being mature, then this is mature enough, if
Object.mixin will be finalized:
```javascript
class Bar extends [M1, M2, M3].reduce(
Object.mixin,
Object.create(Foo.prototype)
) {
// class definition ...
}
```
I must admit that looks weird though ...
Exactly - it might be really cool from the language abilities
perspective, but from the end-users, the example is not that useful:
if the language provides some abstraction (the "class" abstraction in
this particular case), the users which will join to JS starting form
ES6 will have complete right to not even know what that magic
"prototype" mean -- the one which you expose outside actually breaking
the class abstraction. The prototype chain is just the implementation
detail now (and all implementation detail should be hidden in the
best), not a feature.
P.S.: and I still need to choose my English words better :) for the
mature I probably more meant "syntactically solid" rather than a
library method.
But yeah, I promised not to do big off-topic in this for-of thread.
Dmitry
br
On Tue, Jun 11, 2013 at 5:48 PM, Dmitry Soshnikov
<[email protected] <mailto:[email protected]>> wrote:
On Tue, Jun 11, 2013 at 5:33 PM, Brendan Eich
<[email protected] <mailto:[email protected]>> wrote:
Brian Di Palma wrote:
Sorry for the OT message.
On Tue, Jun 11, 2013 at 6:22 PM, Andrea Giammarchi
<[email protected]
<mailto:[email protected]>> wrote:
We don't have interfaces ... I know, we could have
mixins though, compatible
with @@things too.
The concepts of Mixins has cropped up before in
discussions and is
used in current JS code ( EventEmitter ).
I was wondering if it was possible to codify it in ES6 or
is there
simply no bandwidth/time for that?
class MyClass extends MySuper mixin EventEmitter, Iterable {}
What would this syntax do that couldn't be done better by
libraries? Remember that extends' RHS is an expression.
Don't wanna go off-topic of course, but: the the fact that RHS is
an expression might you think Object.mixin(...) can be used there:
class Foo extends Object.mixin(...)
The problem with it as I mentioned (and which was successfully
and unfortunately ignored ;)), it accepts only two arguments
instead of variant to mix several objects.
But even it Object.mixin(...) could accept several arguments, we
still can't extend a class with another class _and_ a set of mixins.
class Bar extends Object.mixin(Foo, M1, M2...), where Foo is a
class and Ms are mixin.
To do this you'll need to either express classes's implementation
details (i.e. to break classes abstraction): class Bar extends
Object.mixin(Foo.prototype, M1...);
Or, yeah, to provide a library method:
class Bar extends classWithMixins(Foo, M1, M2...);
(the later example is actually a real implementation we use in
local projects currently).
Another issue with a library method -- it just looks immature for
a mature language. From this viewpoint:
class Bar extends Foo {
use M1, M2;
}
looks better and mature as all normal OOP langs with
mixins/traits. IMHO.
But as long as ES6 spec is already (almost) stable, I agree it
can be taken to something ES7-ish.
Dmitry
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
