Re: Scoped binding of a method to an object

Hey everyone. I've talked to about 100 developers whose primary language is JS this last week (although I admit it was not a balanced survey, mainly people I know). Most of them (Over 80) do not feel that the problem I've mentioned before in scoped method extensions is a real problem they have to

Re: Scoped binding of a method to an object

On 15 October 2013 17:51, Allen Wirfs-Brock wrote: > On Tue, Oct 15, 2013 at 3:39 AM, Andreas Rossberg > wrote: >> >> On 15 October 2013 03:09, Allen Wirfs-Brock wrote: >> > I still don't get why so many JS programmer with a FP orientation want >> > to do things with the |this| binding. |this|

Re: Scoped binding of a method to an object

On Wed, Oct 16, 2013 at 1:04 AM, Brendan Eich wrote: > No, rather: `b.call(a, x_1, ..., x_n)` but with the original Function.prototype.call (not any shadowing b.call). Right, Russell clarified `::` to me and sent a link to the wiki (always good!). Thanks. > I don't see purr on Cat.prototype --wh

Re: Scoped binding of a method to an object

uhm, never mind, I got it now. Borrowing functions avoiding call/apply looks good. Best Regards On Tue, Oct 15, 2013 at 4:17 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > wait ... what ? > > > On Tue, Oct 15, 2013 at 2:00 PM, Russell Leggett < > russell.legg...@gmail.com> wrote:

Re: Scoped binding of a method to an object

wait ... what ? On Tue, Oct 15, 2013 at 2:00 PM, Russell Leggett wrote: > > > obj::fun(a,b) is not the same as fun(obj,a,b). Its fun.call(obj,a,b). > isn't this basically the equivalent of obj->fun then ? (yes, the other arrow that was an arrow too far) Thanks for clarification ___

Re: Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum October 15, 2013 2:00 PM I think I misunderstood `::` before. if `a::b(x_1,...,x_n)` _just_ means `b(a,x_1,...,x_n)` No, rather: `b.call(a, x_1, ..., x_n)` but with the original Function.prototype.call (not any shadowing b.call). I think

Re: Scoped binding of a method to an object

Thanks, this clarifies things (the difference between having `this` and a first argument is really not that big here at all imo and converting between them two is easy). > What is your ideal SOE form? Because my guess is that I can get it darn close with :: It does seem a lot simpler than actual

Re: Scoped binding of a method to an object

I think I misunderstood `::` before. if `a::b(x_1,...,x_n)` _just_ means `b(a,x_1,...,x_n)` I think it might be a good solution to the chaining problem. I think the `.constructor` proposal as well as being able to do `::` completely eliminates the need for extension methods in this regard. It also

Re: Scoped binding of a method to an object

On Tue, Oct 15, 2013 at 4:28 PM, Benjamin (Inglor) Gruenbaum < ing...@gmail.com> wrote: > Wait, I think maybe I did not understand what you meant before. > > Are we talking about using `::` for infixing the first parameter of the > function? As in `func(a,b,c)` being the same as `a::func(b,c)` ? >

Re: Scoped binding of a method to an object

Wait, I think maybe I did not understand what you meant before. Are we talking about using `::` for infixing the first parameter of the function? As in `func(a,b,c)` being the same as `a::func(b,c)` ? Would that let us do `[1,2,3,4,5]::_.reduce(x=>x%2 === 0)::_.map(x=>2*x)::._.reduce(x,y) => x+y)

Re: Scoped binding of a method to an object

> Using your proposed "underscore2" (OO-underscore?) with :: is no more > verbose than underscore.js (underscore1), and it has the chaining not > inside-out-composing win some may prefer. > I'm glad you noticed the 2. Perhaps oonderscore? :) > > We should not argue only about taste, and bind (::

Re: Scoped binding of a method to an object

Russell Leggett wrote: The big issue I see here is chaining. `_.reduce(_.map(_.filter([1,2,3,4,5],x=>x%2 === 0),x=>2*x),(x,y)=>x+y)` Is a lot less readable than `[1,2,3,4,5].filter(x=>x%2===0).map(x=>2*x).reduce((x,y)=>x+y))` P.S. Thi

Re: Scoped binding of a method to an object

Allen Wirfs-Brock October 14, 2013 6:09 PM Speaking from the perspective of someone whose probably has permanent OO brain damage, it doesn't do a lot for me. The reason I "invoke a method" on an object is because I want to do polymorphic dispatch on the method n

Re: Scoped binding of a method to an object

> > >> The big issue I see here is chaining. >> `_.reduce(_.map(_.filter([1,2,3,4,5],x=>x%2 === 0),x=>2*x),(x,y)=>x+y)` >> Is a lot less readable than >> `[1,2,3,4,5].filter(x=>x%2===0).map(x=>2*x).reduce((x,y)=>x+y))` >> > > P.S. This really doesn't look too shabby to me: import {reduce,map

Re: Scoped binding of a method to an object

On Oct 15, 2013, at 9:44 AM, Benjamin (Inglor) Gruenbaum wrote: > ... > > The big issue I see here is chaining. > `_.reduce(_.map(_.filter([1,2,3,4,5],x=>x%2 === 0),x=>2*x),(x,y)=>x+y)` > Is a lot less readable than > `[1,2,3,4,5].filter(x=>x%2===0).map(x=>2*x).reduce((x,y)=

Re: Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum October 15, 2013 12:45 AM Brendan Eich mailto:bren...@mozilla.com>> wrote: > We already have good motivation for :: anyway, as sugar for bind. This gives relief to the OO side of the expression problem trade-off by allowing lexical bindings t

Re: Scoped binding of a method to an object

> > > > If we didn't have :: (which we don't now), I think people will continue > to simply use functions like what underscore does. Personally, I'm ok with > that > > I think using stuff like _.shuffle([1,2,3,4,5]) is not as nice and worse > than [1,2,3,4,5].shuffle() . Especially in a more functi

Re: Scoped binding of a method to an object

First of all interesting analogy and read. On Tue, Oct 15, 2013 at 5:22 PM, Russell Leggett wrote: > I don't think that the scoped extensions you want are going to happen. I used to like the idea of something like that, but I think it will cause a lot more confusion than its worth. I'm not conv

Re: Scoped binding of a method to an object

On Tue, Oct 15, 2013 at 11:59 AM, Allen Wirfs-Brock wrote: > > On Oct 15, 2013, at 7:22 AM, Russell Leggett wrote: > > > > > If we didn't have :: (which we don't now), I think people will continue > to simply use functions like what underscore does. Personally, I'm ok with > that. If I want to hav

Re: Scoped binding of a method to an object

On Oct 15, 2013, at 7:22 AM, Russell Leggett wrote: > > If we didn't have :: (which we don't now), I think people will continue to > simply use functions like what underscore does. Personally, I'm ok with that. > If I want to have unscoped extensions and live with the consequences - I will >

Re: Scoped binding of a method to an object

On Tue, Oct 15, 2013 at 8:51 AM, Allen Wirfs-Brock wrote: > > On Oct 15, 2013, at 6:40 AM, Mark S. Miller wrote: > > > > > On Tue, Oct 15, 2013 at 3:39 AM, Andreas Rossberg wrote: > >> On 15 October 2013 03:09, Allen Wirfs-Brock >> wrote: >> > I still don't get why so many JS programmer with a FP

Re: Scoped binding of a method to an object

On Oct 15, 2013, at 6:40 AM, Mark S. Miller wrote: > > > > On Tue, Oct 15, 2013 at 3:39 AM, Andreas Rossberg wrote: > On 15 October 2013 03:09, Allen Wirfs-Brock wrote: > > I still don't get why so many JS programmer with a FP orientation want to > > do things with the |this| binding. |t

Re: Scoped binding of a method to an object

On Tue, Oct 15, 2013 at 3:45 AM, Benjamin (Inglor) Gruenbaum < ing...@gmail.com> wrote: > Brendan Eich wrote: > > We already have good motivation for :: anyway, as sugar for bind. This > gives relief to the OO side of the expression problem trade-off by allowing > lexical bindings to be composed

Re: Scoped binding of a method to an object

On Tue, Oct 15, 2013 at 3:39 AM, Andreas Rossberg wrote: > On 15 October 2013 03:09, Allen Wirfs-Brock wrote: > > I still don't get why so many JS programmer with a FP orientation want > to do things with the |this| binding. |this| is for us OO geeks, if you > are doing FP you don't need it. >

Re: Scoped binding of a method to an object

On 15 October 2013 03:09, Allen Wirfs-Brock wrote: > I still don't get why so many JS programmer with a FP orientation want to do > things with the |this| binding. |this| is for us OO geeks, if you are doing > FP you don't need it. Well, 'this' comes up because you cannot avoid having to int

Re: Scoped binding of a method to an object

On Tue, Oct 15, 2013 at 12:50 PM, Andreas Rossberg wrote: > > Arguably, the _syntactic_ complexity is not huge. It is almost benign, > compared to the _semantic_ complexity. Agreed. I have a bit of a problem articulating my thoughts clearly through this medium being new. The problem with introd

Re: Scoped binding of a method to an object

On 14 October 2013 22:10, Benjamin (Inglor) Gruenbaum wrote: >> But there were design issues too. ... user confusion or complexity remains >> an objection. > > Yes! This is the thing that bothers me most right now about scoped extension > methods. Introducing additional syntax to the language seem

Re: Scoped binding of a method to an object

Brendan Eich wrote: > We already have good motivation for :: anyway, as sugar for bind. This gives relief to the OO side of the expression problem trade-off by allowing lexical bindings to be composed with method calls -- beautiful. No third scope axis / lookup parameter! Yeah, but this doesn't s

Re: Scoped binding of a method to an object

On Oct 14, 2013, at 3:58 PM, Brendan Eich wrote: > Russell Leggett wrote: >> It doesn't use dots, so it won't mask the difference between the normal >> prototype chain with some additional scoped binding (for good or ill), but >> along with it comes the clarity and comfort of lexical binding an

Re: Scoped binding of a method to an object

Russell Leggett wrote: It doesn't use dots, so it won't mask the difference between the normal prototype chain with some additional scoped binding (for good or ill), but along with it comes the clarity and comfort of lexical binding and also the potential use of the module system. import

Re: Scoped binding of a method to an object

Russell Leggett October 14, 2013 2:07 PM On Mon, Oct 14, 2013 at 4:05 PM, Brendan Eich > wrote: Russell Leggett > October 14, 2013 12:51 PM

Re: Scoped binding of a method to an object

On Mon, Oct 14, 2013 at 4:05 PM, Brendan Eich wrote: > Russell Leggett > > >> October 14, 2013 12:51 PM >> >> I get that this isn't really the same, but I think one really viable >> solution for the scoped method problem (which is really just the expression >>

Re: Scoped binding of a method to an object

Definitely deep waters here, not one simple thing. Appreciate your interactions. Benjamin (Inglor) Gruenbaum wrote: > But there were design issues too. ... user confusion or complexity remains an objection. Yes! This is the thing that bothers me /most/ right now about scoped extension method

Re: Scoped binding of a method to an object

I think I had a problem articulating my thoughts in this last one. I was trying *not* to tie my cart in front of the horse. Even before worrying about implementer performance issues which sound important I wanted to know if: The problem I had was a real problem to other developers too and it was

Re: Scoped binding of a method to an object

Russell Leggett October 14, 2013 12:51 PM I get that this isn't really the same, but I think one really viable solution for the scoped method problem (which is really just the expression problem, right?) The expression problem (http://en.wikipedia.org/wiki/Ex

Re: Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum October 14, 2013 12:37 PM On Mon, Oct 14, 2013 at 6:44 PM, Brendan Eich > wrote: > So, see the http://scg.unibe.ch/archive/papers/Berg03aClassboxes.pdf work, which inspired Ruby refinements as well as the scoped ob

Re: Scoped binding of a method to an object

I get that this isn't really the same, but I think one really viable solution for the scoped method problem (which is really just the expression problem, right?) is the proposed bind operator http://wiki.ecmascript.org/doku.php?id=strawman:bind_operator It doesn't use dots, so it won't mask the di

Re: Scoped binding of a method to an object

On Mon, Oct 14, 2013 at 6:44 PM, Brendan Eich wrote: > So, see the > 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 w

Re: Scoped binding of a method to an object

Allen Wirfs-Brock October 14, 2013 11:19 AM You can dynamically change the superclass of a class but that will trigger the recompilation process for that class and its subclasses (implies that superclass to subclass links must be available). This is mostly about

Re: Scoped binding of a method to an object

John Lenz October 14, 2013 9:59 AM Does this performance hit still exist in light of Symbol? Yes. Symbol is just an alternative property name type. Think of it in pseudo-ML: type PropertyName = String | Symbol where of course practical engines optimize furt

Re: Scoped binding of a method to an object

On Oct 14, 2013, at 11:06 AM, Brendan Eich wrote: >> Allen Wirfs-Brock >> October 14, 2013 10:52 AM >> >> I'm not sure I buy your "Smalltalk has nominal class types" assertion, > > I defer to your Smalltalk expertise :-P. However, there's nothing I know of > that

Re: Scoped binding of a method to an object

Allen Wirfs-Brock October 14, 2013 10:52 AM I'm not sure I buy your "Smalltalk has nominal class types" assertion, I defer to your Smalltalk expertise :-P. However, there's nothing I know of that allows unrelated class definitions to be related by the subclass r

Re: Scoped binding of a method to an object

On Oct 14, 2013, at 8:42 AM, Brendan Eich wrote: > Andreas Rossberg 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. > > Right. > >

Re: Scoped binding of a method to an object

Does this performance hit still exist in light of Symbol? It seems you could build lexical extensions on top of it without introducing a performance penalty. On Oct 13, 2013 10:49 AM, "Brendan Eich" wrote: > Erik Arvidsson > > >> October 13, 2013 10:32 AM >> W

Re: Scoped binding of a method to an object

Till Schneidereit October 13, 2013 2:39 PM On Sun, Oct 13, 2013 at 8:40 PM, Brendan Eich wrote: Till Schneidereit October 13, 2013 11:28 AM And now it causes problem for TC39, browser vendors, sites that use it and end users.

Re: Scoped binding of a method to an object

Andreas Rossberg 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. Right. The http://scg.unibe.ch/archive/papers/Berg03aClassboxes.pdf work,

Re: Scoped binding of a method to an object

On 13 October 2013 19:49, Brendan Eich wrote: >> Erik Arvidsson >> October 13, 2013 10:32 AM >> >> We did proposes this back in 2011 >> >> http://wiki.ecmascript.org/doku.php?id=strawman:scoped_object_extensions >> >> I wasn't at this actual F2F meeting so I don't

Re: Scoped binding of a method to an object

On Sunday, October 13, 2013, Brendan Eich wrote: > Till Schneidereit wrote: > >> OnSun, Oct 13, 2013 at 11:50 PM, Domenic Denicola >> wrote: >> >>> > From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf >>> Of Benjamin (Inglor) Gruenbaum >>> > >>> >> not to mention stuff l

Re: Scoped binding of a method to an object

Yeah, I don't see how it's going to happen either. Now that I get you meant dynamic as in contrary to lexical scoping having scoped object extensions seems very counter intuitive - especially given the direction the language is heading. Thanks for the discussion. On Mon, Oct 14, 2013 at 1:36 AM,

Re: Scoped binding of a method to an object

Till Schneidereit wrote: OnSun, Oct 13, 2013 at 11:50 PM, Domenic Denicola wrote: > From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Benjamin (Inglor) Gruenbaum > >> not to mention stuff like `.map` or `.reduce` would still return an Array which would result in more

Re: Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum October 13, 2013 2:28 PM Thanks, this really helped me understand the underlying issue here forcing dynamic resolution of scope here. It sounds a lot harder than I initially thought I have to say the fact this is so deeply rooted in the lan

Re: Scoped binding of a method to an object

Rick Waldron wrote: > That's incorrect. XArray.prototype.map would return an XArray instance and reduce always returns what you specify it to return, which can be anything. Domenic Denicola wrote: >This is actually not true as of ES6; ES6 uses `this.constructor` to figure out how to create the r

Re: Scoped binding of a method to an object

On Sun, Oct 13, 2013 at 11:50 PM, Domenic Denicola wrote: > From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of > Benjamin (Inglor) Gruenbaum > >> not to mention stuff like `.map` or `.reduce` would still return an Array >> which would result in more endless wrapping. > > This

RE: Scoped binding of a method to an object

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Benjamin (Inglor) Gruenbaum > not to mention stuff like `.map` or `.reduce` would still return an Array > which would result in more endless wrapping. This is actually not true as of ES6; ES6 uses `this.constructor` to figure

Re: Scoped binding of a method to an object

On Sunday, October 13, 2013, Benjamin (Inglor) Gruenbaum wrote: > This sort of decoration is nice and it's how I usually do this right now, > but this requires me to wrap every array with an `XArray` call which is > tedious, > What do you mean by wrap? Using this looks like: let values = new XAr

Re: Scoped binding of a method to an object

This sort of decoration is nice and it's how I usually do this right now, but this requires me to wrap every array with an `XArray` call which is tedious, not to mention stuff like `.map` or `.reduce` would still return an Array which would result in more endless wrapping. On Sun, Oct 13, 2013 at

Re: Scoped binding of a method to an object

On Sun, Oct 13, 2013 at 8:40 PM, Brendan Eich wrote: >> Till Schneidereit >> 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 >>

Re: Scoped binding of a method to an object

Function traits and mixins are the bread and butter of JS. Being able to share functionality is the pumping heart of prototypical inheritance, especially in a behaviorally typed environment. Much like a possible issue I have with what Rick suggested (although mixins and decoration are not the same

Re: Scoped binding of a method to an object

he 'last' extension, e.g. > > var b = [1, 2, 3]; > alert(b.last()); > > and expected some whole-program transformation (which we do not perform in > JS, too much ambiguity -- think of computed property names, never mind > 'with' and the global object and ev

Re: Scoped binding of a method to an object

If you really have to live with those restriction you do describe, there still is a low level solution working since ES 3 that keeps the implemented codebase of certain behaviors at one place without effecting any other code - function based traits and mixins. One could e.g. write ones own impleme

Re: Scoped binding of a method to an object

On Sun, Oct 13, 2013 at 2:00 PM, Benjamin (Inglor) Gruenbaum < ing...@gmail.com> wrote: > Brendan Eich wrote: > > No, object detection, polyfilling, and even "prollyfilling" are common > and successful adaptationsp on the Web. > > Polyfilling is great _after_ the method has already been added to

Re: Scoped binding of a method to an object

Erik Arvidsson wrote: >... My point is that it seems not everyone heard Mark's statement that weakmaps should not be used to implement relationships except in preprocessors targeting ES6 (assuming we get relationships into ES7). Exactly. Ok, that's what I was hoping for. We need Traceur,

Re: Scoped binding of a method to an object

On Sun, Oct 13, 2013 at 12:45 PM, Kevin Smith wrote: > >>> This is trivial with Symbols: >> >> let shuffle = Symbol(); >> >> Array.prototype[shuffle] = function() {...}; >> >> >> Only code that has access to the `shuffle` symbol may use the method: >> >> let shuffled = array[shuffle](); >>

Re: Scoped binding of a method to an object

On Oct 13, 2013 3:23 PM, "Brendan Eich" wrote: > > Erik Arvidsson wrote: >> >> Let's not kid ourselves. WeakMaps have bad user ergonomics and runtime ergonomics. I think at this point non method functions are much better. > > > Hang on, relationships and new syntax can solve both performance and e

Re: Scoped binding of a method to an object

Erik Arvidsson wrote: Let's not kid ourselves. WeakMaps have bad user ergonomics and runtime ergonomics. I think at this point non method functions are much better. Hang on, relationships and new syntax can solve both performance and ergonomics concerns, we think. Perhaps you missed the Marc

Re: Scoped binding of a method to an object

alert((b instanceof Array) ? Array$prototype$last.call(b) : b.last()); then you have essentially added the third (scope token) parameter by code expansion. Whether ?: or an if statement or polymorphic lookup is used, that's real added runtime cost, and it won't fly. /be ------ F

Re: Scoped binding of a method to an object

>As Brendan points out, doing this in a "scoped" way adds a third parameter representing the scope, or that somehow needs to be scope specific. Such a third parameter needs to be first class. WeakMaps and relationships do exactly that. My relative lack of experience here is probably working agains

Re: Scoped binding of a method to an object

Let's not kid ourselves. WeakMaps have bad user ergonomics and runtime ergonomics. I think at this point non method functions are much better. On Oct 13, 2013 3:00 PM, "Mark S. Miller" wrote: > On Sun, Oct 13, 2013 at 11:36 AM, Benjamin (Inglor) Gruenbaum < > ing...@gmail.com> wrote: > >> First o

Re: Scoped binding of a method to an object

On Sun, Oct 13, 2013 at 11:36 AM, Benjamin (Inglor) Gruenbaum < ing...@gmail.com> wrote: > First of all - well put. > Thanks. > > Second, wouldn't being able to do this in a scoped way solve the conflict > problem? > As Brendan points out, doing this in a "scoped" way adds a third parameter re

Re: Scoped binding of a method to an object

On Oct 13, 2013 2:01 PM, "Benjamin (Inglor) Gruenbaum" wrote: > > Brendan Eich wrote: > > No, object detection, polyfilling, and even "prollyfilling" are common and successful adaptationsp on the Web. > > Polyfilling is great _after_ the method has already been added to the spec. I'm completely f

Re: Scoped binding of a method to an object

> Prollyfilling is great too (perhaps you disagree?), and as its name suggests it happens *before* the method is added to the spec. So in your opinion adding a `.shuffle` method to an Array in a library I ship to users is a good idea if it makes my code clearer and nicer? I'm not saying I disagre

Re: Scoped binding of a method to an object

Till Schneidereit 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 a

Re: Scoped binding of a method to an object

Le 13/10/2013 20:29, Benjamin (Inglor) Gruenbaum a écrit : David Bruant mailto:bruan...@gmail.com>> wrote > This proposal does not aim at solving the problem of library conflicts which existed before this proposal and should be solve independently. Of course, and I'm sorry if I implied otherw

Re: Scoped binding of a method to an object

Adding a prefixing convention is a sure-fire loser, in my experience -- developers hate the dunder-headed prefixing, and it just kicks the can a bit down the road, since plain and desirable names after the prefix will still be contested. /be ___ es-d

Re: Scoped binding of a method to an object

First of all - well put. Second, wouldn't being able to do this in a scoped way solve the conflict problem? On Sun, Oct 13, 2013 at 9:33 PM, Mark S. Miller wrote: > Any library that monkey patches primordials and wishes to be able to rely > on the primordials being mutated only according to it

Re: Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum October 13, 2013 11:00 AM Brendan Eichmailto:bren...@mozilla.com>> wrote: > No, object detection, polyfilling, and even "prollyfilling" are common and successful adaptationsp on the Web. Polyfilling is great _after_ the method has already be

Re: Scoped binding of a method to an object

Any library that monkey patches primordials and wishes to be able to rely on the primordials being mutated only according to it should demand to be run before primordials are otherwise corrupted or frozen, and should freeze the primordials after patching. Of course, such a "library" isn't a library

Re: Scoped binding of a method to an object

David Bruant wrote > This proposal does not aim at solving the problem of library conflicts which existed before this proposal and should be solve independently. Of course, and I'm sorry if I implied otherwise. I'm sure we all acknowledge the problem of extending the native prototypes in librarie

Re: Scoped binding of a method to an object

On Sun, Oct 13, 2013 at 8:05 PM, Brendan Eich wrote: >> Till Schneidereit >> October 13, 2013 10:44 AM >> >> On Sun, Oct 13, 2013 at 7:17 PM, Brendan Eich wrote: >>> >>> Benjamin (Inglor) Gruenbaum wrote: However, this is considered bad practice for ma

Re: Scoped binding of a method to an object

Le 13/10/2013 20:03, Benjamin (Inglor) Gruenbaum a écrit : David Bruant mailto:bruan...@gmail.com>> wrote: > Concretely, attempted prolyfills, could be _-prefixed (that really fits with what you call "poor-man's prefixing", I believe) > Authors would feel free to add something like Array.proto

Re: Scoped binding of a method to an object

On Sun, Oct 13, 2013 at 11:03 AM, Benjamin (Inglor) Gruenbaum < ing...@gmail.com> wrote: > David Bruant wrote: > > Concretely, attempted prolyfills, could be _-prefixed (that really fits > with what you call "poor-man's prefixing", I believe) > > Authors would feel free to add something like Arra

Re: Scoped binding of a method to an object

: Erik Arvidsson To: Brendan Eich Cc: es-discuss Date: Sun, 13 Oct 2013 13:32:23 -0400 Subject: Re: Scoped binding of a method to an object We did proposes this back in 2011 http://wiki.ecmascript.org/doku.php?id=strawman:scoped_object_extensions I wasn't at this actual F2F meeting so I

Re: Scoped binding of a method to an object

Till Schneidereit October 13, 2013 10:44 AM On Sun, Oct 13, 2013 at 7:17 PM, Brendan Eich wrote: Benjamin (Inglor) Gruenbaum wrote: However, this is considered bad practice for many reasons I don't have to repeat here (what if other libraries also override it?

Re: Scoped binding of a method to an object

David Bruant wrote: > Concretely, attempted prolyfills, could be _-prefixed (that really fits with what you call "poor-man's prefixing", I believe) > Authors would feel free to add something like Array.prototype._shuffle or Array.prototype._last, or EventTarget.prototype._on without worrying abou

Re: Scoped binding of a method to an object

Brendan Eich wrote: > No, object detection, polyfilling, and even "prollyfilling" are common and successful adaptationsp on the Web. Polyfilling is great _after_ the method has already been added to the spec. I'm completely fine with adding an Array.prototype.map shim to IE8, the problem with add

Re: Scoped binding of a method to an object

Le 13/10/2013 19:44, Till Schneidereit a écrit : On Sun, Oct 13, 2013 at 7:17 PM, Brendan Eich wrote: Benjamin (Inglor) Gruenbaum wrote: However, this is considered bad practice for many reasons I don't have to repeat here (what if other libraries also override it? What if some user code? What

Re: Scoped binding of a method to an object

Erik Arvidsson October 13, 2013 10:32 AM We did proposes this back in 2011 http://wiki.ecmascript.org/doku.php?id=strawman:scoped_object_extensions I wasn't at this actual F2F meeting so I don't know many details. Brendan might remember what the blocking issue w

Re: Scoped binding of a method to an object

On Sun, Oct 13, 2013 at 7:17 PM, Brendan Eich wrote: > Benjamin (Inglor) Gruenbaum wrote: >> >> However, this is considered bad practice for many reasons I don't have to >> repeat here (what if other libraries also override it? What if some user >> code? What if it makes it to the standard some da

Re: Scoped binding of a method to an object

on properties. This proposal died precise because of the performance >> problem. >> >> /be >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >&

Re: Scoped binding of a method to an object

posal died precise because of the performance problem. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss Benjamin (Inglor) Gruenbaum <mailto:ing...@gmail.com> October 13, 2013 12:54 AM Scoped

Re: Scoped binding of a method to an object

Benjamin (Inglor) Gruenbaum wrote: However, this is considered bad practice for many reasons I don't have to repeat here (what if other libraries also override it? What if some user code? What if it makes it to the standard some day?) Actually, people say extending Object.prototype is bad prac

Re: Scoped binding of a method to an object

On Sun, Oct 13, 2013 at 6:45 PM, Kevin Smith wrote: >>> >> This is trivial with Symbols: >> >> let shuffle = Symbol(); >> >> Array.prototype[shuffle] = function() {...}; >> >> >> Only code that has access to the `shuffle` symbol may use the method: >> >> let shuffled = array[shuffle](); >> >

Re: Scoped binding of a method to an object

> > >> This is trivial with Symbols: > > let shuffle = Symbol(); > > Array.prototype[shuffle] = function() {...}; > > > Only code that has access to the `shuffle` symbol may use the method: > > let shuffled = array[shuffle](); > > Unfortunately, such a construction will fail in a multi-realm

Re: Scoped binding of a method to an object

On Sun, Oct 13, 2013 at 3:54 AM, Benjamin (Inglor) Gruenbaum < ing...@gmail.com> wrote: > Scoped binding of a method to an object > > Well, I know how some languages solve this issue but I wondered if > ECMAScript considered addressing this or already have and I missed it. &g

Scoped binding of a method to an object

Scoped binding of a method to an object Well, I know how some languages solve this issue but I wondered if ECMAScript considered addressing this or already have and I missed it. Often, I want to extend objects, for example - Array.prototype.shuffle - takes an array and shuffles it. However