On Mon, Oct 17, 2011 at 10:13 AM, kmalakoff <xmann.i...@gmail.com> 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/jsmentors@jsmentors.com/
>
> To search via a non-Google archive, visit here:
> http://www.mail-archive.com/jsmentors@googlegroups.com/
>
> To unsubscribe from this group, send email to
> jsmentors+unsubscr...@googlegroups.com
>
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
