

Andro.js - maryrosecook
http://maryrosecook.com/post/andro-js

======
swannodette
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...](https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Proxy),
ClojureScript protocols all provide the machinery to make this kind of thing
work without making the code too hard to reason about.

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

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

------
jcromartie
I wish Node.js had not introduced "evented" as an adjective, leading to
"event" as a verb and "eventer" as a noun...

------
revelation
string hell squared.

~~~
maryrosecook
I'm very open to critique. Can you elaborate?

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

~~~
pavlov
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.)

~~~
jcromartie
I'd rather mistype an identifier than a string literal, because nothing will
complain about the wrong string literal.

