Glad you're still working on this -- it's a really good experiment of the "I would never use this, but would it even work?" variety.
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? :) More optimistically, I don't necessarily agree with the "huge delays" you mention in your follow-up post. It all depends on what you're comparing. Compared to having a constructor already loaded, sure, it will be slower to load an asset on-the-fly. But the goal of PHP's __autoload is not to compete performance-wise vs. having all your classes in a single page -- that would simply not be possible -- but to offer transparent modular loading vs. having to roll your own dependency/switching logic for modular loading. In other words, the incoming assumption is that one-class-per-file or one-package-per-file is going to be in use and the variables are ease-of-use and performance under that umbrella assumption. So making the same assumption w/JS, can you do transparent asset loading with extreme ease-of-use, while incurring minimal performance overhead (of course a fairly small series of function calls in JS can have non-negligible overhead in some machines/browsers)? Just food for thought. -- S. -- Subscription settings: http://groups.google.com/group/mootools-users/subscribe?hl=en
