I know but people use prefixes and unique ids for events too and I am not
sure if that would work so well.

Also, this is not backward compatible, or better, this is impossible to
polyfill so it won't bring benefits to the current scenario.

If only I could already `Object.mixin(Object.mixin({}, EventEmitter),
EventTarget)` and alias those prolix names as `on()` and `off()` it would
be already great but this is too much in between the DOM, behind WebIDL,
and ECMAScript ... something I know already historically incompatible,
that's why I've proposed new names hopefully one day (and hopefully soon)
in core, something that will be inherited in current implementation in any
case, as it was in my case simply polluting the `Object.prototype` with
those non enumerable properties luckily inherited in hosted DOM objects too.

best regards


On Wed, Jul 10, 2013 at 12:46 PM, Matthew Robb <matthewwr...@gmail.com>wrote:

> 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.giammar...@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 <ann...@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@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> - Matthew Robb
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to