On Mon, Apr 19, 2010 at 04:46, Sanford Whiteman <[email protected]
> wrote:
>
> I'm just looking over your code now, but one "out of spec" issue I
> think I see already is that you have to instantiate a Loader (for each
> Class?), and then get an instance of the Loader. This seems to depart
> from the simple goal of emulating 'new <classname>' where <classname>
> doesn't yet have an accompanying constructor defined. Maybe you could
> document your jsFiddle? :)
>
ok - so, yes - this will not supply the same behavior as a true autoloader.
The main issue with writing an autoloader is that Moo Classes pass a
reference to the Classes they implement/extend to the factory method. This
simply will not work with JS with unloaded classes. thus, you need a
separate implementation, that will, after loading the required files, return
a normal Class.
So i created a costum Class factory, not a true class (which actually should
not be called with the new operator IMO:
var b = Loader({...});
//not
var b = new Loader({...});
). Any other solution would require a rewrite of every class i download.
I don't see this as very practical, due to 2 main reasons:
1. At least with this implementation, this will not have any multi-level
inheritance support, unless you rewrite it in the loader (specifically the
Implements and Extends parts of the Class). It simply isn't very ellegant.
2. for this to work properly, every class in the domain will require a new
loader factory for it. this is simply a huge overhead.
so i still believe that as it stands today, other than beeing a very fun
concept to play with, this simply doesn't fit with the current Class
implementation, and, more important, now that the Forge is up and running
(since so many independent classes exists).
--
Subscription settings:
http://groups.google.com/group/mootools-users/subscribe?hl=en
