Based on my understanding of the spec, I'd say that String, Boolean, etc
are not "classes" at all, since they don't have a [[HomeObject]] - they're
just constructor functions.
On Thu, Feb 12, 2015 at 7:55 PM, Gary Guo wrote:
> Actually I disagree with you. `Class` will not be confusing, since as
Please file a bug, ASAP. Thanks,
/be
Michael Ficarra wrote:
Is there any reason why a trailing comma is not allowed in an
ArrayBindingPattern when it has a BindingRestElement? I noticed
yesterday that my parser was erroneously allowing these, but the
inconsistency with both ArrayLiterals and
Actually I disagree with you. `Class` will not be confusing, since as you said,
people probably will use `toStringTag` once per `class`. So `classTag` just
becomes a better name. String, Boolean, etc, are just names of classes.
From: ljh...@gmail.com
Date: Mon, 9 Feb 2015 09:55:01 -0800
Subject:
On Feb 12, 2015, at 7:01 PM, Michael Ficarra wrote:
> Is there any reason why a trailing comma is not allowed in an
> ArrayBindingPattern when it has a BindingRestElement? I noticed yesterday
> that my parser was erroneously allowing these, but the inconsistency with
> both ArrayLiterals and O
Actually, I guess I'm misreading that. It really doesn't allow trailing
commas after a rest element. My bad =)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
> Is this simply a mistake in the grammar?
The grammar appears to allow trailing comma after rest elements, so I think
it’s an implementation error.
> ArrayBindingPattern[Yield,GeneratorParameter] :
>[ Elisionopt BindingRestElement[?Yield, ?GeneratorParameter]opt ]
> [ BindingElementLi
Is there any reason why a trailing comma is not allowed in an
ArrayBindingPattern when it has a BindingRestElement? I noticed yesterday
that my parser was erroneously allowing these, but the inconsistency with
both ArrayLiterals and ObjectBindingPatterns is bothering me. Is this
simply a mistake in
> On Feb 12, 2015, at 1:13 PM, Peter Seliger
> wrote:
>
> As for JavaScript, I strongly believe, Role based composition patterns
> like Mixins or Traits should be function based.
I assume by this you mean that it shouldn’t be a construct and any special
keywords. If that’s the case:
This can
The lastest ES6 draft (Rev 33, Feb. 12, 2015) is now available at
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#february_12_2015_draft_rev_32
Changes include:
Refactoring of module abstract operations to support module loader
specifications
Additional runtime declaratio
As for JavaScript, I strongly believe, Role based composition patterns
like Mixins or Traits should be function based.
Whereas the widely used purely object based approach (together with
some copy mechanics provided by one of the several [extends]
implementations) does still work for Mixins, it is
I know what you’re going for, and I had this in my initial implementation. The
issue then becomes:
If Trait2 mixes in Trait1, does the init method get replaced? Traits are about
inserting functionality, not about inheritance. Example:
trait Trait1 {
init() {
// init Trait1
}
}
Luke, forgot one detail: you do not explicitly initialize traits, these are
initialized if these have an `init` or `initialize` method defined, and
before the constructor is executed. So, using you example code:
```js
trait Trait1 {
initt() {
this.trait1Data = {what:'ever'
Luke, answering in order:
1. defining order, first come, first serve ... same as everything else on
daily usage (events, Array of callbacks, etc)
2. You do not ever pass parameter to them, parameters are constructors
matters, traits should be independent and unaware of constructors arguments
othe
>Why does ES even need traits?
>The only aspect they can help with here is the type system we don't have yet.
>
>We have `Object.assign` that works fantastically for most classic trait use
>cases.
They’d provide a way to explain WebIDL concepts like partial interfaces and
partial dictionaries. T
So we agree traits are not classes and notions, as well as functionality,
is different. Then why would you us `class` to define a trait?
How are you going to recognize them?
I have a library that works already out of the box with traits but these
are not classes, just objects that will enrich cla
> On Feb 12, 2015, at 12:11 PM, Domenic Denicola wrote:
>
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Benjamin Gruenbaum
>
>> We have `Object.assign` that works fantastically for most classic trait use
>> cases.
>
> Well, actually, it works extremely poorly. The
You are also probably forgetting class methods are non enumerable, and
assign works only with enumerable and it copies/assigns retrieved values,
not descriptors.
Please let's drop `Object.assign` from the traits discussion already, since
it won't work with any ES5+ feature, thanks.
On Thu, Feb 12
Traits are different than classical inheritance. They simply copy functionality
into a class as if the method was actually defined in the class. It isn’t
inheritance. It allows you to DRY.
A real world example in my ES6 project:
- Node
- Element extends Node
- Field exte
`Object.assign` is good only to define defaults properties, since it does
not even understand getters and setters, it's really a poor option for
anything trait related.
`Object.assign` is an ES6 introduction based on ES3 assumptions, not even
sure why someone would consider it for traits.
Moreove
Sorry, forgot to CC the list
> From: Benjamin Gruenbaum
> Date: February 12, 2015 at 22:19:14 GMT+2
> To: Domenic Denicola
> Subject: Re: about lightweight traits
>
> Those points are good, let me try to address them
>
> State - In other languages like C# and swift the issue with adding custom
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Benjamin
Gruenbaum
> We have `Object.assign` that works fantastically for most classic trait use
> cases.
Well, actually, it works extremely poorly. The old (now dead or deferred)
`Object.mixin`, once called `Object.define`,
So you are saying we can just forget about extends keyword and use mixin
instead for everything, right?
-Original Message-
From: "Alex Russell"
Sent: 12/02/2015 20:05
To: "Andrea Giammarchi"
Cc: "Luke Scott" ; "es-discuss@mozilla.org"
Subject: Re: about lightweight traits
Traits a
Why does ES even need traits?
The only aspect they can help with here is the type system we don't have yet.
We have `Object.assign` that works fantastically for most classic trait use
cases.
> On Feb 12, 2015, at 18:35, Andrea Giammarchi
> wrote:
>
> Without going down full specification/impl
Traits as class make perfect sense when you consider that classes are
functions and so are traits.
On Thu, Feb 12, 2015 at 10:27 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> this thousand times ... Traits as class makes no sense to me indeed and
> Mark example shows plain objects
I am working on a proposal that I intend to bring to the next TC39
meeting. The (very much in need of updating) gist for my proposal is here:
https://gist.github.com/jeffmo/054df782c05639da2adb
(Note that this gist is from July of last year, which was before we
eliminated @@create and imposed t
When I brought this up my thoughts were to have the classes flattened to a
linear inheritance model. Yeah this means an ownProp copy from the
constructor for statics and the prototype for instance onto methods. That
might be a limitation but currently class syntax is javascript's nicest way
to desc
> On Feb 12, 2015, at 10:27 AM, Andrea Giammarchi
> wrote:
>
> this thousand times ... Traits as class makes no sense to me indeed and Mark
> example shows plain objects passed as Trait.create ... that works just fine,
> except some trait initialization, which should not be a constructor, cou
this thousand times ... Traits as class makes no sense to me indeed and
Mark example shows plain objects passed as Trait.create ... that works just
fine, except some trait initialization, which should not be a constructor,
could be used too.
Is there any other language that uses same classical OOP
> On Feb 12, 2015, at 8:35 AM, Andrea Giammarchi
> wrote:
>
> Without going down full specification/implementation details, does anyone
> believe that classes should/could be used, in the future, as traits/mixins
> too?
>
> I find that an anty pattern.
>
> I think traits should be just plai
I would agree.
How would you use classes as traits -- are you talking about multiple
inheritance? Or flattened to a linear inheritance model?
On 12 February 2015 at 16:35, Andrea Giammarchi wrote:
> Without going down full specification/implementation details, does anyone
> believe that classes
As pretty everyone already seen, generators are usually used in composition
with promises to yield (pun intended) a plain simple linear code. This
solution looks very much like monads from Haskell, yet in a better syntax:
every a <- b in Haskell is a = yield b in JS, and that aids to get rid of
sev
On Thu, Feb 12, 2015 at 8:35 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> Without going down full specification/implementation details, does anyone
> believe that classes should/could be used, in the future, as traits/mixins
> too?
>
I do. But I am in no rush. Classes need to gro
Without going down full specification/implementation details, does anyone
believe that classes should/could be used, in the future, as traits/mixins
too?
I find that an anty pattern.
I think traits should be just plain objects with an initializer or some
special object flagged as trait and I'd ra
33 matches
Mail list logo
