Hi Jake, When I originally developed the library, I only used my owns mixins and I knew the require paths using CommonJS, but when I packaged my library, I wanted to provide a flexible mechanism for mixins authors to find one another's mixins. The best mechanism I could come up with was using strings and a central registry of mixins.
In this topic, I am looking for recommendations on how to allow mixin writers to manage the dependencies between mixins when using and not using CommonJS. Any recommendations are much appreciated! Kevin On Oct 17, 11:28 am, Jake Verbaten <[email protected]> wrote: > On Mon, Oct 17, 2011 at 10:13 AM, kmalakoff <[email protected]> wrote: > > 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. > > The fact you used a name is one way to do it, the other way to do it is > dependency injection > > var createAspect = function (requiredAspect1, requiredAspect2) { > // return and make aspect > > > > > > > > } > > > 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] -- 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]
