Loader vs ES6 Classes
johnjbarton at google.com
Mon Aug 4 13:23:05 PDT 2014
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 <guybedford at gmail.com> 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 <jason.orendorff at gmail.com>
>> On Sun, Aug 3, 2014 at 2:31 PM, Kevin Smith <zenparsing at gmail.com> wrote:
>> > I've often wondered why we aren't using inheritance to customize
>> > I'd be interested in the rationale.
>> When I was working on Loaders, I modified the design so that inheritance
>> 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.
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss