Andro.js(maryrosecook.com)
maryrosecook.com
Andro.js
http://maryrosecook.com/post/andro-js
13 comments
Nice post! It's interesting that hardly anyone has chimed in that some programming language features make addressing this problem considerably simpler without forcing the programmer to write excess boilerplate. Objective-C delegation, JavaScript Proxies https://developer.mozilla.org/en/JavaScript/Reference/Global..., ClojureScript protocols all provide the machinery to make this kind of thing work without making the code too hard to reason about.
I really like the loosely coupled approach.
However, I think that sprinkling andro.eventer all over the place is a stumbling block to me - it's essentially a global variable.
I realise that you don't want to polute the objects too much, but why not just add bind and emit methods to the composed object? Either that or pass andro as a parameter to the mixin's setup method?
Also, the bind(this, "touch", function...) to me looks like you're binding to the "touch" event of "this". Is the closure tax really so high that you can't store "this", or use something like jQuery.proxy()?
Like I said, I think this approach has a lot of potential, and seems to fit quite naturally the eventful model that the DOM uses.
However, I think that sprinkling andro.eventer all over the place is a stumbling block to me - it's essentially a global variable.
I realise that you don't want to polute the objects too much, but why not just add bind and emit methods to the composed object? Either that or pass andro as a parameter to the mixin's setup method?
Also, the bind(this, "touch", function...) to me looks like you're binding to the "touch" event of "this". Is the closure tax really so high that you can't store "this", or use something like jQuery.proxy()?
Like I said, I think this approach has a lot of potential, and seems to fit quite naturally the eventful model that the DOM uses.
Thank you for your excellent feedback.
Yes, andro.eventer is there to avoid polluting the owner object. However, your idea of passing andro to the behaviour's setup() method is a great one. I'm going to give it a try.
The reason I require the behaviour to be passed to bind() is so that the passed function can be run with `this` set to the behaviour. I couldn't see another way to let bind know which behaviour should be bound to the event.
Yes, andro.eventer is there to avoid polluting the owner object. However, your idea of passing andro to the behaviour's setup() method is a great one. I'm going to give it a try.
The reason I require the behaviour to be passed to bind() is so that the passed function can be run with `this` set to the behaviour. I couldn't see another way to let bind know which behaviour should be bound to the event.
I wish Node.js had not introduced "evented" as an adjective, leading to "event" as a verb and "eventer" as a noun...
string hell squared.
I'm very open to critique. Can you elaborate?
I cant speak for that guy but my take is that all of the strings except rarrr should statically defined in the object that defines their behaviour. They may even be integers instead of strings to speed things up. Then you would need some way to avoid collision for the event integers shared across many objects.
Repeating strings is hard to refactor and comparing strings is much less efficient than comparing integers. Think about making sure every bit in two 2 * 8 * length string of bits plus overhead is the same vs two 32bit integers. The latter far fewer cycles.
Repeating strings is hard to refactor and comparing strings is much less efficient than comparing integers. Think about making sure every bit in two 2 * 8 * length string of bits plus overhead is the same vs two 32bit integers. The latter far fewer cycles.
I'm not convinced this is useful JavaScript optimization advice. JavaScript doesn't have integers, and string literals are interned, so it shouldn't make a substantial difference if you have the same literal written out 15 times or just defined once and placed in a property. (In fact, using the plain literal everywhere may be faster because it omits the dynamic property access.)
I'd rather mistype an identifier than a string literal, because nothing will complain about the wrong string literal.
Excellent point. I would normally do this, but I wanted to reduce the amount of indirection in the code as much as possible. But, it may still be worth doing so people aren't distracted by thinking "Wow, this girl should use constants".
Strings can work fine for event names, I think op is overstating the string hell factor. But say you wanted to eliminate them you could do something like:
var firstTouchBehaviour = {
touchCount: 0,
events: {
firstTouch: 'FirstTouch'
},
setup: function(owner) {
andro.eventer(owner).bind(this, "touch", function(contact) {
if(contact === "added") {
if(this.touchCount === 0) {
andro.eventer(owner).emit(this.events.firstTouch);
}
this.touchCount++;
} else if(contact === "removed") {
this.touchCount--;
}
});
}
};
var soundBehaviour = {
setup: function(owner) {
andro.eventer(owner).bind(this, firstTouchBehaviour.events.firstTouch , function() {
console.log("Rarrrrrwwwwwwwwwwwwwwww");
});
}
};Yes, I agree.
What would you do instead?