Loader vs ES6 Classes

Kevin Smith zenparsing at gmail.com
Mon Aug 4 18:33:24 PDT 2014


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 <waldron.rick at gmail.com> 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 <johnjbarton at google.com>
> 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 <calvin.metcalf at gmail.com>
>> 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 <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>
>>>> wrote:
>>>>
>>>>> 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
>>>>> 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
>>>>> es-discuss at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140804/1a1bb99d/attachment.html>


More information about the es-discuss mailing list