Scoped binding of a method to an object

Brendan Eich brendan at
Mon Oct 14 08:44:48 PDT 2013

> Till Schneidereit <mailto:till at>
> October 13, 2013 2:39 PM
> On Sun, Oct 13, 2013 at 8:40 PM, Brendan Eich<brendan at>  wrote:
>>> Till Schneidereit<mailto:till at>
>>> October 13, 2013 11:28 AM
>>> And now it causes problem for TC39, browser vendors, sites that use it and
>>> end users. (The last group should be affected the least because the first
>>> three groups work together to prevent it, of course.)
>> I think we agree. My point was that the objections are not definitive, not
>> axiomatic enough. The costs are born "later" and "by others". This is a
>> recipe for social ills.
> Ok, we do agree, then.

This kind of problem is also part of life as we know it, in many 
domains. I don't have a general solution :-).

>> What we do about it is up to us, but just asserting that developers should
>> stop extending primordials sounds like King Canute to me.
> Also agreed.
> It's still not entirely obvious to me what exactly we should do about
> it, sadly. And not only now, but going forward. Cow path paving
> requires the cows' ability to trod on the same ground that might be
> paved later. That very fact means that the cow paths might end up
> colliding with paved streets.

Have you ever driven in town in Boston, Massachusetts, USA? :-P

>   I don't see how this basic conundrum can
> be resolved without a scope based resolution-mechanism (no pun
> intended).

If namespaces and scoped object extensions have fallen, what is left? I 
agree with Andreas Rossberg, who just wrote

"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."

So, see the 
work, which inspired Ruby refinements as well as the scoped object 
extensions strawman, and try to come up with compile-time-complete 


More information about the es-discuss mailing list