Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum inglor at gmail.com
Mon Oct 14 12:37:47 PDT 2013


On Mon, Oct 14, 2013 at 6:44 PM, Brendan Eich <brendan at mozilla.com> wrote:
> So, see the http://scg.unibe.ch/archive/**papers/Berg03aClassboxes.pdf<http://scg.unibe.ch/archive/papers/Berg03aClassboxes.pdf> work,
which inspired Ruby refinements as well as the scoped object extensions
strawman, and try to come up with compile-time-complete resolution.

Wait a minute, does this mean that the *major* blocking step in this
proposal is the speed?

Are we in agreement that given the performance issue is solved we:

 a) Want this sort of feature/ability in the language with the extra syntax
it entails at all?
 b) Want it enough to ask browser vendors actually implement it in their JS
engines?
 c) Want it enough to actually write down a clear scope resolution
algorithm that decdes when to choose extension methods?

Because I thought that the problem you've had with it is that it creates
more confusing scoping *to the user.*



On Mon, Oct 14, 2013 at 6:44 PM, Brendan Eich <brendan at mozilla.com> wrote:

> Till Schneidereit <mailto:till at tillschneidereit.**net<till at tillschneidereit.net>
>> >
>> October 13, 2013 2:39 PM
>>
>> On Sun, Oct 13, 2013 at 8:40 PM, Brendan Eich<brendan at mozilla.com>
>>  wrote:
>>
>>> Till Schneidereit<mailto:till@**tillschneidereit.net<till at tillschneidereit.net>
>>>> >
>>>> 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 http://scg.unibe.ch/archive/**papers/Berg03aClassboxes.pdf<http://scg.unibe.ch/archive/papers/Berg03aClassboxes.pdf>work, which inspired Ruby refinements as well as the scoped object
> extensions strawman, and try to come up with compile-time-complete
> resolution.
>
> /be
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131014/b75eae96/attachment.html>


More information about the es-discuss mailing list