You can do chainability at object define time with the sugar form:

var obj = {
on type1(){},
on type2(){},
on type3(){}
}

OR add to it using one of the following options:

Object.mixin(obj, {
on type1(){},
on type2(){},
on type3(){}
})

obj.{
on type1(){},
on type2(){},
on type3(){}
}

obj := {
on type1(){},
on type2(){},
on type3(){}
}


On Wed, Jul 10, 2013 at 12:41 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> my implementation works already with `DOM` nodes and browser environment,
> including `window`.
>
> I've also already written an `EventTarget` mixin object but in my case I'd
> use that via `Object.mixin(Object.prototype, EventTarget);` 'cause almost
> every object I use in my logic should be observed or should emit something
> to some other object.
>
> Of course Dictionaries are out of the game but that's OK, as long as it's
> possible to promote them later on via `Object.setPrototypeOf(dict,
> Object.proottype)`
>
> I find the `Object.addEventListener(obj, "type", handler)` approach very
> boring for the simple reason that it does not make sense to use
> chainability there, another de-facto thing when it comes to events.
>
> ```javascript
> // current eddy.js status
> var obj = {}
>   .on(type1, handler1)
>   .on(type2, handler2)
>   .on(type3, handler3)
> ;
> ```
> This allows multiple operations with the same object, something not
> possible with the `Object.publicStatic` alternative if not repeating same
> thing many times.
>
> The chainability won here in both jQuery and node.js world, together with
> many other libraries.
>
> I know it's hard to even think about polluting the `Object.prototype` but
> indeed FirefoxOS uses events all over the place, node.js is basically 90%
> event driven, so is the DOM, and every observable object is firing
> indirectly events for third parts.
>
> What else do we need to understand that maybe we could simplify this in
> core and make event driven development **way easier** and finally more
> standard?
>
> Even keeping the double firing approach, both `trigger` and `emit` since
> these two do different things (slightly, but still...)
>
> Last wonder, nobody said a word about the `.boundTo(method)` solution for
> a very very common/frequent problem.
>
> Thanks for all other thoughts though, best regards.
>
>
>
>
>
>
> On Wed, Jul 10, 2013 at 11:42 AM, Anne van Kesteren <annevk at annevk.nl>wrote:
>
>> Yeah, so what I meant was how you'd stop the madness if you don't do
>> them in a way that works with DOM (as DOM works today). My bad.
>>
>>
>> --
>> http://annevankesteren.nl/
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
- Matthew Robb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130710/b247a190/attachment.html>

You can do chainability at object define time with the sugar form:

```js
var obj = {
  on type1(){},
  on type2(){},
  on type3(){}
}
```

OR add to it using one of the following options:

```js
Object.mixin(obj, {
  on type1(){},
  on type2(){},
  on type3(){}
})

obj.{
  on type1(){},
  on type2(){},
  on type3(){}
}

obj := {
  on type1(){},
  on type2(){},
  on type3(){}
}
```