Note 1. ECMAScript. Bound functions.
in [JavaScript]
|
From: Dmitry A. Soshnikov on 13 Jun 2010 13:48 Hello, Here is the new article, which is in the "Notes" (<URL: http://dmitrysoshnikov.com/notes/ >) section. "Note 1. ECMAScript. Bound functions." -- <URL: http://dmitrysoshnikov.com/notes/note-1-ecmascript-bound-functions/ > Additions and corrections are welcome. Dmitry.
From: Asen Bozhilov on 13 Jun 2010 15:50 Dmitry A. Soshnikov wrote: > "Note 1. ECMAScript. Bound functions." -- <URL:http://dmitrysoshnikov.com/notes/note-1-ecmascript-bound-functions/> The article is good and useful. | Function.prototype.bind (thisArg [, arg1 [, arg2, ...]]) | 15.3.4.5 | 4. Let F be a new native ECMAScript object . That step is described by ECMA-262-5 without any conditions. And the following behavior is conformance: function F(){} var thisValue = {}; print(F.bind(thisValue) !== F.bind(thisValue)); //true I do not see any purposes for that design. The design of `bind' permit memory optimizations but unfortunately ECMA-262-5 does not describe that.
From: Dmitry A. Soshnikov on 14 Jun 2010 06:46 On 13.06.2010 23:50, Asen Bozhilov wrote: > Dmitry A. Soshnikov wrote: > >> "Note 1. ECMAScript. Bound functions." --<URL:http://dmitrysoshnikov.com/notes/note-1-ecmascript-bound-functions/> > > The article is good and useful. > Yes, there two main goals which distinguish built-in implementation from the JavaScript's `bind` implementations: (1) with `new` operator `this` value refers to the newly created object, but not to bound one; (2) it's not possible to implement the spec's behavior in JavaScript of the `new` bound functions (such as e.g. in "Prototype.js"): there if you return `this` manually, you'll return bound `this`; if you return "nothing" (implicit `this` value logically mention) -- then the result is indeterminate and dependent on the return value of a bound function. Alternatively, I would propose to separate these two tasks: static bound `this` value is for "bind", and currying is for "curry" method (how it's called in other languages). > | Function.prototype.bind (thisArg [, arg1 [, arg2, ...]]) > | 15.3.4.5 > | 4. Let F be a new native ECMAScript object . > > That step is described by ECMA-262-5 without any conditions. And the > following behavior is conformance: > > function F(){} > var thisValue = {}; > print(F.bind(thisValue) !== F.bind(thisValue)); //true > > I do not see any purposes for that design. The design of `bind' permit > memory optimizations but unfortunately ECMA-262-5 does not describe > that. > Yep, they could mention this optimization. If the function is the same (with the same lexical environment chain), then, if there are no pre-bound partial args, the bound functions should not be different. P.S.: for testing I used again BESEN implementation which is (after small bug fixes made today) are completely conformant in the question of "bind". Dmitry.
From: Richard Cornford on 14 Jun 2010 07:38 On Jun 14, 11:46 am, Dmitry A. Soshnikov wrote: > On 13.06.2010 23:50, Asen Bozhilov wrote: <snip> >> | Function.prototype.bind (thisArg [, arg1 [, arg2, ...]]) >> | 15.3.4.5 >> | 4. Let F be a new native ECMAScript object . > >> That step is described by ECMA-262-5 without any conditions. >> And the following behavior is conformance: > >> function F(){} >> var thisValue = {}; >> print(F.bind(thisValue) !== F.bind(thisValue)); //true > >> I do not see any purposes for that design. The design of `bind' >> permit memory optimizations but unfortunately ECMA-262-5 does >> not describe that. > > Yep, they could mention this optimization. If the function is > the same (with the same lexical environment chain), then, if > there are no pre-bound partial args, the bound functions should > not be different. <snip> Remember that javascript's functions (including functions returned from calls to - bind -) are objects and so may, at any future time, have properties added and values assigned to those properties. var a = F.bind(thisValue); var b = F.bind(thisValue); a.something = 'test'; Do you now expect - b - to have a property called 'something' and for that property to have the value 'test'? And worse, would you want the existence of - b.something - to depend on an optional optimisation where it may be there in some environments and not there in others? As things stand, ES5 guarantees that each function returned from a call to - bind - has unique identity, and so that an implementation behave as if it has unique identity. I think that this is a good thing. Richard.
From: Asen Bozhilov on 14 Jun 2010 09:46
Richard Cornford wrote: > Remember that javascript's functions (including functions returned > from calls to - bind -) are objects and so may, at any future time, > have properties added and values assigned to those properties. > var a = F.bind(thisValue); > var b = F.bind(thisValue); > > a.something = 'test'; It can depend on setter/getter and it is not necessary the assigned value to be accessed by: b.something; > Do you now expect - b - to have a property called 'something' and for > that property to have the value 'test'? And worse, would you want the > existence of - b.something - to depend on an optional optimisation > where it may be there in some environments and not there in others? As > things stand, ES5 guarantees that each function returned from a call > to - bind - has unique identity, and so that an implementation behave > as if it has unique identity. I think that this is a good thing. Certainly true, but in the near future we will see the approaches like: for (var i = 0, len = coll.length; i < len; i++) { coll[i].onclick = function () { //.... }.bind(thisValue); } And by ECMA-262 should be created `len' * 2 objects. Would you want implementations to follow that or they will make optimizations behind the scene and behind the ECMA-262 standard? |