I've implemented (2) & (3) and created a new branch which contains the changes:
https://github.com/Polymer/NodeBind/tree/noUnbind (here's the CL: https://codereview.appspot.com/76140044/). This change improved the binding benchmark (at 100% density with O.o enabled, but no compound bindings or expressions) by about 35%: https://github.com/Polymer/TemplateBinding/blob/master/benchmark/index.html and the codereview-diff.html benchmark(with O.o enabled) by about 15%: https://github.com/Polymer/TemplateBinding/blob/master/benchmark/codereview-diff.html I leave it to Scott & Steve to let me know when/if Polymer-dev would like to integrate this change (by not using unbind/unbindAll anymore). On Sun, Mar 9, 2014 at 10:23 AM, Rafael Weinstein <[email protected]>wrote: > Hello all, > > I'd like to propose two repo/design changes: > > 1) Merge the NodeBind Repo into TemplateBinding. > > This will basically mean just moving the source & tests from NodeBind into > TemplateBinding. This doesn't really change the design of the system (at > least yet), but it does acknowledge that these two things really go > together. It's one less repo to deal with and it means that we can > eventually write a single pseudo-spec for the whole system and have it be > in one place. > > 2) Remove Node.prototype.unbind, Node.prototype.unbindAll. > > It's somewhat less clear to me that nodes should ever be unbind-able > (rebind-able, or imperatively bind-able beyond template instancing, for > that matter). The only use-case we've encountered for doing this is > cleaning up (shutting down observation). However, if WeakRefs become > available in ES or if TemplateBinding/NodeBind get standardized (and > therefore make weak references available from c++), cleaning up observation > can be a concern of the node itself, and not require external interaction. > > Thus, the current design where Node.prototype.bind() is returning a > "close-able" object is really only internal API for the prollyfill. > > The main motivation for doing this is perf. Unbinding and setting up the > .bindings object during construction are significant work. > > I know that Polymer is currently using unbind and unbindAll(), but my > proposal is for polymer to do what TemplateBinding does, which is to keep > an array of closeable objects for each fragment that will eventually need > to be cleaned up, rather than traverse a fragment and unbind all nodes. > > 3) Make Node.prototype.bindings run-time enable-able. > > Again, this is significant work for which I know of only one use case > (which is tooling -- e.g. the sandbox app). > > I propose that we allow the bindings of a Node to be reflectable only if > some well known switch is enabled. This is analogous to devtools using > internal APIs to enable reflection. > > Concerns? > > > Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CABMdHiQL804e8GU0B%2BS2LxZc3gdXkpHcfHu3_7cos-FGDDY4VQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
