domenic at domenicdenicola.com (2013-07-16T14:51:43.787Z)
On Wed, Jul 10, 2013 at 7:22 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
> tis works same way you can define toString during class definition ... so
> what happens, nothing unexpected.
This response completely dodges the point I've made and toString is a poor
comparison. toString is only one method and it's expected that a class (or
previously Constructor.prototype.toString) would define it's own toString
with an appropriate return value.
> I think you didn't understand what is boundTo ... completely a part from
> events.
No, I understood it just fine. I was just listing out every method listed
here https://github.com/WebReflection/eddy#event-driven-js but you snipped
the rest of the sentence, so now it's out of context.
> 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.
What I'm saying is: let's agree to an Emitter and make it a standard
library module.
> it's also more semantic than `node.addEventListener('load')` since you say
> and write and mean `node.on('load');`
What are you talking about? Look again at the example I'm commenting on and
explain to me how to register two different handlers for an event named
"type1". Yes, addEventListener sucks. Yes, on("foo", handler) is great.
> 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.
Of course, I was referring to the syntactic form that Matthew proposed:
```js
var obj = {
on foo() {}
}
```
(this is still part of my point above, re: registering multiple handlers
for the same named event)
> If there was a mechanism to have that simplified today I believe it would
> have been used.
It may not be "simple" by your definition (it isn't simple by mine), but
it's the most common practice...
```js
var Emitter = require("events").EventEmitter;
function Foo() {
Emitter.call(this);
}
Foo.prototype = Object.create(Emitter.prototype);
Foo.prototype.constructor = Foo;
```
Which corresponds to:
```js
class Foo extends Emitter {
constructor() {
super()
}
}
```
Maybe I'm missing something in your argument here? If so, I apologize.
> So are you willing to talk about that standard EventEmitter and put it in
> ASAP as native constructor every object could inherit from ?
I absolutely stand by championing such a standard module.
> '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)
Well, any object right?
inline... On Wed, Jul 10, 2013 at 7:22 PM, Andrea Giammarchi < andrea.giammarchi at gmail.com> wrote: > 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. > This response completely dodges the point I've made and toString is a poor comparison. toString is only one method and it's expected that a class (or previously Constructor.prototype.toString) would define it's own toString with an appropriate return value. > > > > >> boundTo methods that are actually useless now. >> > > I think you didn't understand what is boundTo ... completely a part from > events. > No, I understood it just fine. I was just listing out every method listed here https://github.com/WebReflection/eddy#event-driven-js but you snipped the rest of the sentence, so now it's out of context. > > 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. > What I'm saying is: let's agree to an Emitter and make it a standard library module. > > 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 are you talking about? Look again at the example I'm commenting on and explain to me how to register two different handlers for an event named "type1". Yes, addEventListener sucks. Yes, on("foo", handler) is great. > 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. > Of course, I was referring to the syntactic form that Matthew proposed: var obj = { on foo() {} } (this is still part of my point above, re: registering multiple handlers for the same named event) > > > >>>>> 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. > It may not be "simple" by your definition (it isn't simple by mine), but it's the most common practice... var Emitter = require("events").EventEmitter; function Foo() { Emitter.call(this); } Foo.prototype = Object.create(Emitter.prototype); Foo.prototype.constructor = Foo; Which corresponds to: class Foo extends Emitter { constructor() { super() } } Maybe I'm missing something in your argument here? If so, I apologize. > > > >> >> >>> >>>>> 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 ? > I absolutely stand by championing such a standard module. > > '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) > Well, any object right? Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130710/da8f682c/attachment-0001.html>