Hi everyone, Out of the discussion with Jake, also there was a clarification on why I used names instead of constructors directly to identify a mixin (see below), and why I put initialize and destroy outside the object.
I needed a general-purpose way for mixins (which may be dependent on other mixins) to find one another irregardless of the developers directly structure when they use or don't use CommonJS. The name was a way to puncture through the require paths. Also, I put the initilize outside the object to avoid clobbering, to give a clear reference to the initalize and destroy functions which may be called multiple times, and also to avoid polluting the mix target with those extra methods which are in a sense private to the mixin system rather than part of the public interface. Is there a better way to do this? Kevin ***** > Why would you want to register a mixin by string name? A mixin should just > be an object. KM> Originally I was using objects. The problem I ran into was that I was using CommonJS that required a path to the object so when I packaged the library and sample mixins I needed to 1) find a way to provide users the flexibility to pick and choose which mixins they use and 2) to not force a specific directory and file structure for them but let them choose how they lay things out. The answer I came up with was "named loose coupling" but if there is a better solution, I'm happy to apply it - just let me know. KM> Use case: one user doesn't use CommonJS and all of their mixins are in the global namespace; another users uses CommonJS and layouts out their mixin files in "vendor", and a different user puts other people's mixins under "vendor/mixin" and their own mixins in a lib folder: "lib/my_mixins" ****** > *Mixin.initialize* > The object you "register" has properties like it's name (why should it have > a name, just use the object reference) > It also has an initialize method, why can't that live on the object (my > personal preference is using `.constructor`) 2) I decoupled the initialize method and put it outside the object was to avoid clobbering between mixins and to not have a fixed new/destroy call order, but something on-the-fly and dynamic. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
