Note 1. ECMAScript. Bound functions.
in [JavaScript]
|
From: Dmitry A. Soshnikov on 15 Jun 2010 05:23 On 15.06.2010 13:02, Dmitry A. Soshnikov wrote: > On 15.06.2010 12:48, Asen Bozhilov wrote: >> Dmitry A. Soshnikov wrote: >>> Asen Bozhilov wrote: >> >>>> Yes that is true, but is it too far? For example with built in >>>> `Object.create' and `bind' you cannot create an instance by bound >>>> function. Built-in `bind' return function object who does not have >>>> `prototype' property. So in normal case `Object.create' should throw >>>> TypeError. You should need explicitly define `prototype' property and >>>> after that create an instance. >>> >>> What do you mean? Object.create accepts any object as a future prototype >>> of the being created object. It doesn't matter, whether you define >>> `prototype' property on bound function and pass `BoundF.prototype' to >>> the Object.create, or just a single object. >> >> var F = (function () {}).bind(obj); >> >> print(F.prototype); //undefined >> Object.create(F.prototype); //TypeError >> >> So as I said for creating instance you should explicit define >> `prototype' property and after that use, `Object.create'. >> > > Ah, but that's I said -- the fact that you pass F.prototype won't mean > that you created an instance of _exactly_ F. You can do this simply > passing any object, not necessary F.prototype: > > Object.create({ > constructor: F > }); > > That I meant. > It can confuse, I mean, in any case even if you define `BoundF.prototype' and pass it to the `Object.create', `instanceof' operator won't work. Only if you change `TargetF.prototype': function F() {} var BoundF = F.bind(null); var a = new BoundF; print(a instanceof BoundF); // true print(a instanceof F); // true var boundProto = { constructor: BoundF, x: 200 }; BoundF.prototype = boundProto; var b = Object.create(BoundF.prototype); // false, because of overloaded [[HasIntance]], // which delegates to F.[[HasIntance]] print(b instanceof BoundF); print(b instanceof F); // of course, false var c = Object.create(boundProto); // change target's prototype F.prototype = boundProto; print(c instanceof BoundF); // true print(c instanceof F); // true print(b instanceof BoundF); // true print(b instanceof F); // true Dmitry.
From: Dmitry A. Soshnikov on 15 Jun 2010 05:24 On 15.06.2010 13:17, Asen Bozhilov wrote: > Dmitry A. Soshnikov wrote: >> Asen Bozhilov wrote: > >>> So as I said for creating instance you should explicit define >>> `prototype' property and after that use, `Object.create'. >> >> Ah, but that's I said -- the fact that you pass F.prototype won't mean >> that you created an instance of _exactly_ F. You can do this simply >> passing any object, not necessary F.prototype: >> >> Object.create({ >> constructor: F >> >> }); >> >> That I meant. > > Created object here is not an instance of `F'. See example: > > function F() { > print(this instanceof F); > } > > var obj = Object.create({constructor : F}); > obj.constructor(); > > That object just has constructor property which refer `F' it is not > instance of `F'. So in that case I will pass bounded thisValue to > target function instead of treat as `new Bound();' > You already figured out my confusing, while I was writing clarification ;) See previous reply -- `instanceof' won't work in any case in testing with a bound function. Dmitry.
From: Dmitry A. Soshnikov on 15 Jun 2010 06:54 On 15.06.2010 13:23, Dmitry A. Soshnikov wrote: > On 15.06.2010 13:02, Dmitry A. Soshnikov wrote: >> On 15.06.2010 12:48, Asen Bozhilov wrote: >>> Dmitry A. Soshnikov wrote: >>>> Asen Bozhilov wrote: >>> >>>>> Yes that is true, but is it too far? For example with built in >>>>> `Object.create' and `bind' you cannot create an instance by bound >>>>> function. Built-in `bind' return function object who does not have >>>>> `prototype' property. So in normal case `Object.create' should throw >>>>> TypeError. You should need explicitly define `prototype' property and >>>>> after that create an instance. >>>> >>>> What do you mean? Object.create accepts any object as a future >>>> prototype >>>> of the being created object. It doesn't matter, whether you define >>>> `prototype' property on bound function and pass `BoundF.prototype' to >>>> the Object.create, or just a single object. >>> >>> var F = (function () {}).bind(obj); >>> >>> print(F.prototype); //undefined >>> Object.create(F.prototype); //TypeError >>> >>> So as I said for creating instance you should explicit define >>> `prototype' property and after that use, `Object.create'. >>> >> >> Ah, but that's I said -- the fact that you pass F.prototype won't mean >> that you created an instance of _exactly_ F. You can do this simply >> passing any object, not necessary F.prototype: >> >> Object.create({ >> constructor: F >> }); >> >> That I meant. >> > > It can confuse, I mean, in any case even if you define > `BoundF.prototype' and pass it to the `Object.create', `instanceof' > operator won't work. Only if you change `TargetF.prototype': > > function F() {} > > var BoundF = F.bind(null); > > var a = new BoundF; > > print(a instanceof BoundF); // true > print(a instanceof F); // true > > var boundProto = { > constructor: BoundF, > x: 200 > }; > > BoundF.prototype = boundProto; > > var b = Object.create(BoundF.prototype); > > // false, because of overloaded [[HasIntance]], > // which delegates to F.[[HasIntance]] > print(b instanceof BoundF); > print(b instanceof F); // of course, false > > var c = Object.create(boundProto); > > // change target's prototype > F.prototype = boundProto; > > print(c instanceof BoundF); // true > print(c instanceof F); // true > print(b instanceof BoundF); // true > print(b instanceof F); // true > Another confusing (but conforming) behavior of the `instanceof' is testing an object created from a _non-bound_ constructor with a bound one: var object = new F; alert([ object instanceof F, // true object instanceof BoundF, // true ]); I've updated the article mentioning all these cases. Dmitry.
From: Dmitry A. Soshnikov on 15 Jun 2010 08:18 On 15.06.2010 0:46, Dmitry A. Soshnikov wrote: <snip> > I remember one discussion (but can't find it now, if you'll find, let me > know) where joined objects are recognized as not so needed, so I guess > they were removed from ES5 because of that. Found it: <URL: http://www.mail-archive.com/es4-discuss(a)mozilla.org/msg00082.html> This is separate replies acknowledge that "joined objects" were mistake of ES3: <URL: http://www.mail-archive.com/es4-discuss(a)mozilla.org/msg00089.html> <URL: http://www.mail-archive.com/es4-discuss(a)mozilla.org/msg00117.html> Dmitry.
From: Garrett Smith on 17 Jun 2010 18:59
On 6/15/2010 12:00 AM, Garrett Smith wrote: > On 6/14/2010 7:08 PM, pedz wrote: >> On Jun 14, 6:49 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >>> It is mentioned in the code guidelines doc in three places: >>> >>> http://jibbering.com/faq/notes/code-guidelines/#design >> [about goog.isDef] FAQ entry proposal regarding: >> Also, reading a little further, the term "nonstandard" might be >> avoided. The function statement, it says, is "nonstandard" but it is >> in the 3 and 5 standards. The key point is that it is "allowed" and >> not "required" and it is that choice of the implementers that make it >> a bad choice to use. Calling something in the standards a nonstandard >> isn't helping the unenlightened. > > No, a Function statement is not defined by either 3 or 5 editions. > Function statement is a nonstandard syntax extension. > > Please take a look at the FAQ and see if that doesn't clear things up > for you. > http://jibbering.com/faq/#functionStatement > > Asen noted that function declaration appearing where only statements are > allowed will result in a SyntaxError in BESEN and DMDScript. I plan to > add that to the FAQ. Currently, we have: > > | Implementations that have the function statement extension process > | Fze as a Statement, in order, while other known implementations > | evaluate Fze upon entering the execution context that it appears in. > | For consistent behavior across implementations, avoid function > | statement; use either FunctionExpression or FunctionDeclaration > | instead. > > I'd like to change the FAQ to mention that. > <FAQENTRY> > Proposed: > | Implementations that have the function statement extension process > | Fze as a Statement, in order. Others, including JScript, evaluate Fze > | upon entering the execution context that it appears in. Yet others, > | notably BESEN and DMDScript, throw a SyntaxError. > | > | For consistent behavior across implementations, do not use function > | statement; use either FunctionExpression or FunctionDeclaration > | instead. </FAQENTRY> Garrett |