<div dir="ltr"><div>On Mon, Oct 14, 2013 at 6:44 PM, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.com" target="_blank">brendan@mozilla.com</a>></span> wrote:<br></div>> So, see the <a href="http://scg.unibe.ch/archive/papers/Berg03aClassboxes.pdf" target="_blank">http://scg.unibe.ch/archive/<u></u>papers/Berg03aClassboxes.pdf</a> work, which inspired Ruby refinements as well as the scoped object extensions strawman, and try to come up with compile-time-complete resolution.<div>

<span class=""><br></span></div><div><span class="">Wait a minute, does this mean that the <i>major</i> blocking step in this proposal is the speed?</span></div><div><span class=""><br></span></div><div><span class="">Are we in agreement that given the performance issue is solved we:</span></div>

<div><span class=""><br></span></div><div><span class=""> a) Want this sort of feature/ability in the language with the extra syntax it entails at all?</span></div><div><span class=""> b) Want it enough to ask browser vendors actually implement it in their JS engines?</span></div>

<div><span class=""> c) Want it enough to actually write down a clear scope resolution algorithm that decdes when to choose extension methods?</span></div><div><br></div><div>Because I thought that the problem you've had with it is that it creates more confusing scoping <i>to the user.</i></div>

<div><br></div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Oct 14, 2013 at 6:44 PM, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.com" target="_blank">brendan@mozilla.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


Till Schneidereit <mailto:<a href="mailto:till@tillschneidereit.net" target="_blank">till@tillschneidereit.<u></u>net</a>><br>
October 13, 2013 2:39 PM<div class="im"><br>
On Sun, Oct 13, 2013 at 8:40 PM, Brendan Eich<<a href="mailto:brendan@mozilla.com" target="_blank">brendan@mozilla.com</a>>  wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


Till Schneidereit<mailto:<a href="mailto:till@tillschneidereit.net" target="_blank">till@<u></u>tillschneidereit.net</a>><br>
October 13, 2013 11:28 AM<br>
<br>
And now it causes problem for TC39, browser vendors, sites that use it and<br>
end users. (The last group should be affected the least because the first<br>
three groups work together to prevent it, of course.)<br>
</blockquote>
I think we agree. My point was that the objections are not definitive, not<br>
axiomatic enough. The costs are born "later" and "by others". This is a<br>
recipe for social ills.<br>
</blockquote>
<br>
Ok, we do agree, then.<br>
</div></blockquote>
<br>
This kind of problem is also part of life as we know it, in many domains. I don't have a general solution :-).<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


What we do about it is up to us, but just asserting that developers should<br>
stop extending primordials sounds like King Canute to me.<br>
</blockquote>
<br>
Also agreed.<br>
<br>
It's still not entirely obvious to me what exactly we should do about<br>
it, sadly. And not only now, but going forward. Cow path paving<br>
requires the cows' ability to trod on the same ground that might be<br>
paved later. That very fact means that the cow paths might end up<br>
colliding with paved streets.<br>
</blockquote>
<br></div>
Have you ever driven in town in Boston, Massachusetts, USA? :-P<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  I don't see how this basic conundrum can<br>
be resolved without a scope based resolution-mechanism (no pun<br>
intended).<br>
</blockquote>
<br></div>
If namespaces and scoped object extensions have fallen, what is left? I agree with Andreas Rossberg, who just wrote<br>
<br>
"My take-away was that scoped extension methods are only bearable in a language with a static, nominal class system (like C#), where the additional lookup dimension can be resolved at compile time."<br>
<br>
So, see the <a href="http://scg.unibe.ch/archive/papers/Berg03aClassboxes.pdf" target="_blank">http://scg.unibe.ch/archive/<u></u>papers/Berg03aClassboxes.pdf</a> work, which inspired Ruby refinements as well as the scoped object extensions strawman, and try to come up with compile-time-complete resolution.<span class=""><font color="#888888"><br>


<br>
/be<br>
</font></span></blockquote></div><br></div></div></div>