domenic at domenicdenicola.com (2013-07-13T01:59:55.934Z)
On Wed, Jul 10, 2013 at 3:57 PM, Rick Waldron <waldron.rick at gmail.com>wrote:
> I don't want any of this on my Object objects. Not all objects represent
> something that can or should emit/publish/trigger/broadcast.
tis works same way you can define toString during class definition ... so
what happens, nothing unexpected.
> boundTo methods that are actually useless now.
I think you didn't understand what is boundTo ... completely a part from events.
You can bind any method or function, borrowed or not, and only once, I
don't see how you can do the same with current proposal in ES6
`genericObject.boundTo(genericMethod)` returns always the same bound object.
This is actually trivial enough as utility since chainability is not even
an option.
> 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?
Because in 10 years I haven't seen such standard Emitter so it's about the
time to agree on an event based mechanism, IMO, since we all talk about
events in every asynchronous world.
Object.observer ain't good for all cases but only for few of them. We all
know how powerful are events.
> This is the dark days of DOM element properties as event handlers:
>
> ```js
> elem.onclick...
> ```
it's also more semantic than `node.addEventListener('load')` since you say
and write and mean `node.on('load');`
What's less semantic is `.off()` if you want, but it works as counter part.
And back to the light, I would rather use `switch(onOrOff) {}` as method
> Assigning to this paves over the previous assignment, leaving no way to
> have multiple handlers registered for the same event type.
You are right, in that inline version this is correct.
I didn't propose that indeed and you can use more than a handler without
problems.
> Standard lib approach (a la node) works today and tomorrow.
it works in the meaning that in node you give for granted that basically every object is an EventEmitter.
If there was a mechanism to have that simplified today I believe it would have been used.
> It's also (subjectively) hideous.
agreed
> That's great for your use case, but I would never want this by default.
So are you willing to talk about that standard EventEmitter and put it in
ASAP as native constructor every object could inherit from ?
'cause this would be already a lot for me and everyone else out there, a
native way to have emitters in core (hopefully able to work with DOM nodes
too)
inline ... On Wed, Jul 10, 2013 at 3:57 PM, Rick Waldron <waldron.rick at gmail.com>wrote: > 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 > } > } > tis works same way you can define toString during class definition ... so what happens, nothing unexpected. > boundTo methods that are actually useless now. > I think you didn't understand what is boundTo ... completely a part from events. You can bind any method or function, borrowed or not, and only once, I don't see how you can do the same with current proposal in ES6 genericObject.boundTo(genericMethod) returns always the same bound object. This is actually trivial enough as utility since chainability is not even an option. 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? > Because in 10 years I haven't seen such standard Emitter so it's about the time to agree on an event based mechanism, IMO, since we all talk about events in every asynchronous world. Object.observer ain't good for all cases but only for few of them. We all know how powerful are events. > var obj = { >>> on type1(){}, >>> on type2(){}, >>> on type3(){} >>> } >>> >> > This is the dark days of DOM element properties as event handlers: > > elem.onclick... > > it's also more semantic than `node.addEventListener('load')` since you say and write and mean `node.on('load');` What's less semantic is `.off()` if you want, but it works as counter part. And back to the light, I would rather use `switch(onOrOff) {}` as method > Assigning to this paves over the previous assignment, leaving no way to > have multiple handlers registered for the same event type. > You are right, in that inline version this is correct. I didn't propose that indeed and you can use more than a handler without problems. >>>> 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. > it works in the meaning that in node you give for granted that basically every object is an EventEmitter. If there was a mechanism to have that simplified today I believe it would have been used. > > >> >>>> 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. > agreed > > > >> >>>> ```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. > So are you willing to talk about that standard EventEmitter and put it in ASAP as native constructor every object could inherit from ? 'cause this would be already a lot for me and everyone else out there, a native way to have emitters in core (hopefully able to work with DOM nodes too) Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130710/baf7f276/attachment.html>