4 ms·
Why is there a Gator function when the only interface is `Gator(x).on(e, s, c)` and `Gator(x).off(e, s, c)`? Why not `Gator.on(x, e, s, c)` and rely on the cal
by strager 14y ago
Why is there a Gator function when the only interface is `Gator(x).on(e, s, c)` and `Gator(x).off(e, s, c)`? Why not `Gator.on(x, e, s, c)` and rely on the caller to do partial function application (e.g. with `Function.prototype.bind`)? This seems like unnecessary memory bloat[1].
[1] https://github.com/ccampbell/gator/blob/0c8fafad45202c018706082d976b2cf4430e7b84/gator.js#L264-L278 https://github.com/ccampbell/gator/blob/0c8fafad45202c018706...
- crescentfresh 14y agoProbably for "chaining", like all the cool libraries do now.
- strager 14y agoGator .on(x, e1, s1, c1) .on(x, e2, s2, c2) ; Or is chaining desired after partial application (meaning `x` is chained)? var onX = chainFn(Gator.on, x); onX (e1, s1, c1) (e2, s2, c2) ; It seems that a library can provide chaining if needed.
- craigc 14y agoThanks for the comment. I considered that, but I was thinking it makes things a little cleaner/easier to maintain by using Gator objects. Only one object instance is created per element. Also it allows for chaining methods.
- crescentfresh 14y ago> Only one object instance is created per element I think the point may be "Gator.on()" wouldn't need instances of anything allocated. But then you lose chaining.
- strager 14y agoI see. Still, your approach leaks memory as it maintains references to nodes which may otherwise be GC'able. Have you considered `WeakMap` for caching (where supported)?
- craigc 14y agoThat's a good point. I probably will add some sort of destroy method. I figure in most cases with delegation you are referencing an element that is not likely to be removed (such as document), but I probably should add a way to clean up stale objects. As for WeakMap, I wasn't even aware of that, looks awesome.