> On Monday, August 4, 2014 11:48 AM, Axel Rauschmayer <a...@rauschma.de> wrote:
> > On Aug 4, 2014, at 16:33 , John Barton <johnjbar...@google.com> wrote:
> > As far as I can tell you are basically arguing that simple Loader hooks
> > don't need object state. Of course that is true.
> No, I’m arguing that Juan’s code is basically “subclassing” a loader,
> overriding a method and calling that method. ES6 classes seem like a more
> elegant way of doing this. You’d get as much object state in the subclass as
> you want.
We are actually using state a lot for configuration. And there's ongoing
discussion about how to do it. So far we've been extending the Loader instance
with our own properties (e.g. loader.depCache = {}). The main reason is that we
want our extensions to the loader to work both on new instances of the Loader
class and on the System loader, which can't be subclassed.
Also, we want each of our extensions to the loader to be self-contained. The
reason is that apps that have critical performance needs need to be able to
pick the extensions they want instead of bundling everything in case they need
them. Subclassing doesn't quite get along with this approach. We also expect
performance critical applications to insert their loader extensions in the HTML
page or to PUSH them using SPDY. This way, in browsers that have the Loader
API, we avoid this situation:
Fetch HTML page -> Fetch Loader extensions -> Fetch the app's code
Some links to current discussion:
- Conditional loading configuration:
https://github.com/systemjs/systemjs/issues/126
- Reconsidering extension process again:
https://github.com/systemjs/systemjs/issues/158
- Package configuration: https://github.com/systemjs/systemjs/issues/141
-Juan
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
