- From: Dimitri Glazkov <dglazkov@google.com>
- Date: Fri, 8 Mar 2013 09:51:35 -0800
- To: Blake Kaplan <mrbkap@gmail.com>
- Cc: public-webapps <public-webapps@w3.org>, Scott Miles <sjmiles@google.com>, Elliott Sprehn <esprehn@google.com>, Steve Orvell <sorvell@google.com>, Daniel Buchner <daniel@mozilla.com>, Adam Klein <adamk@google.com>, Hajime Morrita <morrita@google.com>, Blake Kaplan <mrbkap@mozilla.com>, William Chen <wchen@mozilla.com>
On Wed, Mar 6, 2013 at 4:26 PM, Blake Kaplan <mrbkap@gmail.com> wrote: > On Wed, Mar 6, 2013 at 1:55 PM, Dimitri Glazkov <dglazkov@google.com> wrote: >> 1) Somehow magically chain "create" callbacks. In Lucy's case, >> <foo-lucy> will call both Raj's and Lucy's callbacks. >> 2) Get rid of a separate lifecycle object and just put the callbacks >> on the prototype object, similar to printCallback >> (http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jan/0259.html) > >> I am leaning toward the second solution, but wanted to get your opinions. > > I also like the second solution, but Hajime's point about the > mutability and general exposure of the lifecycle methods is a good > one. Is there a motivation for having the lifecycle objects on the > prototype as opposed to being passed in as an "ancestor" parameter? > XBL1, as I understand it, automatically calls the > constructor/destructor of "extended" bindings, but given the ad hoc > nature of web components' inheritance, it seems like it would be much > less surprising to make this stuff explicit *somewhere* (i.e. in the > actual components rather than in the engine). I think the idea of placing callbacks on the prototype was the simplest to do, given that prototype inheritance provides all the right machinery. If we deem this being a terrible idea, we'll need to fallback to something like passing ancestor. But then we'll be going against the grain of JS. :DG<
Received on Friday, 8 March 2013 17:52:07 UTC