I don't want any of this on my Object objects. Not all objects represent
something that can or should emit/publish/trigger/broadcast.
For example...
class Light {
constructor() {
// initialize Light control instance
}
on() {
// send bits to turn Light on
}
off() {
// send bits to turn Light off
}
}
So what happens now? All of my Led instances have emit, trigger, once and
boundTo methods that are actually useless now. No thanks. I also don't want
Object.prototype.* and Object.* to suffer the same way that the [[Global]]
(window) object in browsers has suffered. Give a hoot, don't pollute.
Post ES6 world makes creating emitter objects trivial—so why not a blessed
standard lib module that can be imported and used to extend a class
declaration?
import { Emitter } from "@event";
class Foo extends Emitter {}
Easy.
More inline...
On Wed, Jul 10, 2013 at 3:58 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> 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(){}
>> }
>>
>
This is the dark days of DOM element properties as event handlers:
elem.onclick...
Assigning to this paves over the previous assignment, leaving no way to
have multiple handlers registered for the same event type.
>
>> 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.
>>>
>>
Standard lib approach (a la node) works today and tomorrow.
>
>>> 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.
>>>
>>
It's also (subjectively) hideous.
>
>>> ```javascript
>>> // current eddy.js status
>>> var obj = {}
>>> .on(type1, handler1)
>>> .on(type2, handler2)
>>> .on(type3, handler3)
>>> ;
>>> ```
>>>
>>
That's great for your use case, but I would never want this by default.
Rick
(snip)
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
