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.giammarchi at 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 <matthewwrobb at 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.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.
>>>
>>
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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130710/753f1a92/attachment.html>

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...

```js
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?

```js
import { Emitter } from "@event";

class Foo extends Emitter {}
```

Easy.

More inline...



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

> You can do chainability at object define time with the sugar form:
>
> ```js
> var obj = {
>   on type1(){},
>   on type2(){},
>   on type3(){}
> }
> ```

This is the dark days of DOM element properties as event handlers:

```js
elem.onclick...
```

Assigning to this paves over the previous assignment, leaving no way to
have multiple handlers registered for the same event type.

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.

Standard lib approach (a la node) works today and tomorrow.


> 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.