If I understand correctly, John was wanting to use a state-carrying options as the options argument when specifying hook overrides. I think the best solution would be to simply remove the options argument altogether (unless there's still a good reason to keep it).
On Mon, Aug 4, 2014 at 8:52 PM, Rick Waldron <[email protected]> wrote: > Sorry for the top post. Can someone provide a concrete example of how ES6 > classes fall down here? > > Rick > > > On Mon, Aug 4, 2014 at 2:28 PM, John Barton <[email protected]> > wrote: > >> The System object is global, so "depends" is the answer to all such >> questions. >> >> >> On Mon, Aug 4, 2014 at 2:24 PM, Calvin Metcalf <[email protected]> >> wrote: >> >>> Would the System object for a module loaded with a sub classed System be >>> the sub classed one or the original one? >>> IMO a better design would have each platform subclass Loader, eg >>> SystemLoader extends Loader and System (or 'system' if we decide to >>> suddenly come to our senses) would be an instance of SystemLoader. >>> SystemLoader would define the hook functions and custom Loader classes >>> would extend SystemLoader to add features. Custom loaders probably don't >>> want to re-implement the hooks so much as augment them. The SystemLoader >>> would support this naturally. >>> >>> >>> >>> >>> On Mon, Aug 4, 2014 at 12:52 PM, Guy Bedford <[email protected]> >>> wrote: >>> >>>> I suppose the point is whether System can be subclassed itself, since >>>> that is usually the starting point for a new loader as it is common >>>> to share the base environment normalization, locate and fetch functions. >>>> >>>> Currently, if System is set via the options hooks this isn't possible. >>>> >>>> Note also that things like baseURL and the mapping table being created >>>> through the constructor would also make sharing these easier. >>>> >>>> If System were defined to be based on a class found at >>>> System.constructor like this, things get a lot easier for that >>>> starting point. >>>> >>>> >>>> On Monday, August 4, 2014, Jason Orendorff <[email protected]> >>>> wrote: >>>> >>>>> On Sun, Aug 3, 2014 at 2:31 PM, Kevin Smith <[email protected]> >>>>> wrote: >>>>> > I've often wondered why we aren't using inheritance to customize >>>>> Loaders. >>>>> > I'd be interested in the rationale. >>>>> >>>>> When I was working on Loaders, I modified the design so that >>>>> inheritance works. >>>>> >>>>> That is, you can just subclass Loader and declare the methods you want >>>>> to override, and the Loader will call those methods. It all works, as >>>>> far as I can tell. >>>>> >>>>> I don't remember why we kept the options argument after that. I'm in >>>>> favor of dropping it. >>>>> >>>>> -j >>>>> _______________________________________________ >>>>> es-discuss mailing list >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
