> but about the coparison between PHP's autoload and CS-JS, i must > disagree. on PHP, the overhead is with milliseconds, and can easily > be made efficiant through caching. On CS-JS, no matter what you do, > you will still be doing more calls to the server (by default this > would be for every missing class),
Not necessarily to the server... with proper caching, only the first request would be to the server, subsequent ones from the local cache even after browser restart. And taking into account single-page rich web apps, there are a lot of cases where there is only one HTTP request needed. It'd be foolish for me to argue that multiple HTTP requests, even once per sesession, won't be much, much slower than loading .class files from the server-side filesystem. But that wasn't ever debatable. My point is that the only reason to embark on an __autoload emulation (which at least 4 of us are still into!) in client-side JS would be if you have already have made the decision to use a file-per-class or file-per-package architecture -- just as the PHP feature is built to accomodate an existing programming tradition. So assume you already will be incurring overhead when you load the classes. The question is whether building a transparent autoloader can be done well enough -- adding little enough overhead/pseudo-keywords/stylistic changes -- to be superior to manually listing and loading dependencies. -- S. -- Subscription settings: http://groups.google.com/group/mootools-users/subscribe?hl=en
