<div dir="ltr">The System object is global, so "depends" is the answer to all such questions.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 4, 2014 at 2:24 PM, Calvin Metcalf <span dir="ltr"><<a href="mailto:calvin.metcalf@gmail.com" target="_blank">calvin.metcalf@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Would the System object for a module loaded with a sub classed System be the sub classed one or the original one? </p>
<div class="HOEnZb"><div class="h5">
<div style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div>


<br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 4, 2014 at 12:52 PM, Guy Bedford <span dir="ltr"><<a href="mailto:guybedford@gmail.com" target="_blank">guybedford@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<div>


<br></div>
<div>Currently, if System is set via the options hooks this isn't possible.</div><div><br></div>Note also that things like baseURL and the mapping table being created through the constructor would also make sharing these easier.<br>



<div><br></div><div>If System were defined to be based on a class found at System.constructor like this,<span></span> things get a lot easier for that starting point.<div><div><br><br>On Monday, August 4, 2014, Jason Orendorff <<a href="mailto:jason.orendorff@gmail.com" target="_blank">jason.orendorff@gmail.com</a>> wrote:<br>



</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Sun, Aug 3, 2014 at 2:31 PM, Kevin Smith <<a>zenparsing@gmail.com</a>> wrote:<br>


> I've often wondered why we aren't using inheritance to customize Loaders.<br>
> I'd be interested in the rationale.<br>
<br>
When I was working on Loaders, I modified the design so that inheritance works.<br>
<br>
That is, you can just subclass Loader and declare the methods you want<br>
to override, and the Loader will call those methods. It all works, as<br>
far as I can tell.<br>
<br>
I don't remember why we kept the options argument after that. I'm in<br>
favor of dropping it.<br>
<br>
-j<br></div></div><div>
_______________________________________________<br>
es-discuss mailing list<br>
<a>es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</div></blockquote></div>
<br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></div>
</div></div></blockquote></div><br></div>