It looks like we agree traits are **not** classes so that classes should
not be used or accepted as traits ... which is already an answer to my
initial question.
Other "problems"
init is a special case, as constructor is. You don't need a constructor to
create an instance, you might not need to i
> 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
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
...@gmail.com> wrote:
>
> So you are saying we can just forget about extends keyword and use mixin
> instead for everything, right?
> --
> From: Alex Russell
> Sent: 12/02/2015 20:05
> To: Andrea Giammarchi
> Cc: Luke Scott ; es-discuss@mozill
> 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
n Thu, Feb 12, 2015 at 9:19 PM, Benjamin Gruenbaum
wrote:
> 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
t; <mailto:es-discuss@mozilla.org>
> Subject: Re: about lightweight traits
>
> 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
> mailto:andrea.giammar...@gmail.
`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 swi
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"
Subje
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
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
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
24 matches
Mail list logo
