Code Guidelines
in [JavaScript]
|
Prev: Dynamic iframe caching problem workaround needed for Firefox
Next: JavaScript code mangler / scrambler / ... khm, more than obfuscator... :)
From: Garrett Smith on 28 Dec 2009 23:49 Asen Bozhilov wrote: > Garrett Smith wrote: >> Asen Bozhilov wrote: >> >> Move that paren inwards, to group the FunctionExpression, as: >> (function(){})(); > > What is the difference between: > > typeof function(){}(); > > (function(){}()); > > (function(){})(); > > Please explain. > > >>> Expected value of `x` is `null`, but if VO is implement as a native >>> object value of `x` will be 10. Because: >> [...] >> >> If - VO - is a variable object, then it must have no [[Prototype]]. > > But documentation permit VO to have [[Prototype]] from: > > | 10.1.4 Scope Chain and Identifier Resolution > | 2. Call the [[HasProperty]] method of Result(1), passing the > Identifier as the property. > > I don't think that is a bug in Blackberry9000, because documentation > permit that behavior. That is implementation-dependent too. > That actually seems to be correct. A program cannot access the activation object, but there's nowhere I read that activation object cannot have a [[Prototype]]. If the variable object has a [[Prototype]], then identifier resolution behaves differently. We disucssed this before... http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/ec2ffbc979c65cc4/ Can Activation Object have a [[Prototype]]? I'm posting this question to es-discuss. ES5 has what is called "Lexical Environment" and I do not know if [[Prototype]] is explicitly forbidden for that object. Am I missing something? > Btw 1: In FAQ link above "BlackBerry JavaScript Reference" > <URL: http://docs.blackberry.com/en/developers/deliverables/8861/> > Links in that page ares broken. They redirect me to: > <URL: http://docs.blackberry.com/404error.jsp> > Oh, that's no good. > Proper URL is: > <URL: http://docs.blackberry.com/en/developers/deliverables/11849/> > Ah, thanks, fixed locally. > Btw 2: Why not include in "Code Guidelines" `delete` operator over a > host objects, because host object can implement own internal > [[Delete]] method and using `delete` operator for host objects can be > error-prone. > Certainly it can be. IE throws errors with delete on window properties, though not on global variables. var x = 10; this.y = 11; delete x; // false; delete y: // error. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Asen Bozhilov on 29 Dec 2009 09:08 Dmitry A. Soshnikov wrote: > var foo = function () { > alert(arguments[0]); > > } > > (function () {return 'x';})() > > Meanwhile, this form (where we've also "forgot" semicolon after `foo') > will throw an exception. Thank for that example. It can be very hard to catch that, especially if returned value from `foo` is a reference to object which have internal [[Call]] method. var foo = function () { return arguments[0]; } (function () {return 'x';})(); Expected behavior in unexpected way. var foo = function () { return function(){}; } (function () {return 'x';})(); There are no error, and absolutely unexpected behavior in first look, but actually is it normal and expected behavior.
From: Dmitry A. Soshnikov on 29 Dec 2009 09:14 On Dec 29, 5:08 pm, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote: > Dmitry A. Soshnikov wrote: > > var foo = function () { > > alert(arguments[0]); > > > } > > > (function () {return 'x';})() > > > Meanwhile, this form (where we've also "forgot" semicolon after `foo') > > will throw an exception. > > Thank for that example. It can be very hard to catch that, especially > if returned value from `foo` is a reference to object which have > internal [[Call]] method. > > var foo = function () { > return arguments[0]; > > } > > (function () {return 'x';})(); > > Expected behavior in unexpected way. > > var foo = function () { > return function(){}; > > } > > (function () {return 'x';})(); > > There are no error, and absolutely unexpected behavior in first look, > but actually is it normal and expected behavior. Yep, absolutely right. /ds
From: Asen Bozhilov on 29 Dec 2009 11:43 Garrett Smith wrote: > Certainly it can be. IE throws errors with delete on window properties, > though not on global variables. > > var x = 10; > this.y = 11; > delete x; // false; > delete y: // error. ^; Typo correction ;~) More suggestions for "Code Guidelines". Doesn't have information: - About `11.10 Binary Bitwise Operators` and how they converted operands `ToInt32`. Which mean, with `Bitwise Operators` can loose precision. See below: var x = Math.pow(2, 30); window.alert(x); //1073741824 window.alert(x & x); //1073741824 x = Math.pow(2, 34); window.alert(x); //17179869184 window.alert(x & x); //0 - About comparison of NaN values: window.alert(NaN === NaN); //false window.alert(isNaN(NaN)); //true - In which cases primitive values will be converted automatically ToObject and ToObject with which values throw TypeError. window.alert('str'.concat); try { null.foo; }catch(e) { window.alert(e instanceof TypeError); //true } try { with(undefined); }catch(e) { window.alert(e instanceof TypeError); //true } - About for-in loops. That is related with augmentation of built-in objects prototype chain and with my previous item. try { for (var i in null); }catch(e) { window.alert(e); } I'm cannot found browser ECMA-262 implementation which follow the specification in `12.6.4 The for-in Statement` step 3 in `for ( LeftHandSideExpression in Expression ) Statement` and step 4 in `for ( var VariableDeclarationNoIn in Expression )` | Call ToObject(GetValue(Expression)) Only in "DMD Script" i get a expected behavior in relation to ECMA 262-3 12.6.4.
From: Garrett Smith on 29 Dec 2009 13:48
Asen Bozhilov wrote: > Garrett Smith wrote: > >> Certainly it can be. IE throws errors with delete on window properties, >> though not on global variables. >> >> var x = 10; >> this.y = 11; >> delete x; // false; >> delete y: // error. > ^; > Typo correction ;~) > I added under DOM section: Host Objects: * Operators: - DO not use delete operator with host object (IE Errors) * Accessing Host objects that are or can be ActiveX objects. These may include, but are not limited to: - Disconnected nodes (node.offsetParent) - XMLHttpRequest methods - style filters ES5 requires all Host object to implement HasProperty, along with [[Get]], [[Delete]], [[DefaultValue]], et al (see Table 8). This is a big step in the right direction and I'm optimistic of more such things from the committee. > More suggestions for "Code Guidelines". > > Doesn't have information: > - About `11.10 Binary Bitwise Operators` and how they converted > operands `ToInt32`. Which mean, with `Bitwise Operators` can loose > precision. See below: > I don't often see such mistake. The last I remember seeing it was John Resig's blog around 2007 or so, related to failed ES4. If you have an example of a piece of code that suffered a bug because of it, I'd be happy to include it. It would be worth recommending:- For numeric conversion, use unary + operator, for parsing numbers from strings, use parseInt(s, radix); > window.alert(NaN === NaN); //false > window.alert(isNaN(NaN)); //true > > - In which cases primitive values will be converted automatically > ToObject and ToObject with which values throw TypeError. > > window.alert('str'.concat); > > try { > null.foo; > }catch(e) { > window.alert(e instanceof TypeError); //true > } > > try { > with(undefined); > }catch(e) { > window.alert(e instanceof TypeError); //true > } > I don't understand. What you are suggesting? > - About for-in loops. That is related with augmentation of built-in > objects prototype chain and with my previous item. > > try { > for (var i in null); > }catch(e) { > window.alert(e); > } > > I'm cannot found browser ECMA-262 implementation which follow the > specification in `12.6.4 The for-in Statement` step 3 in `for > ( LeftHandSideExpression in Expression ) Statement` and step 4 in `for > ( var VariableDeclarationNoIn in Expression )` > | Call ToObject(GetValue(Expression)) > > Only in "DMD Script" i get a expected behavior in relation to ECMA > 262-3 12.6.4. > No TypeError, huh? You might want to mention that observation on es-discuss mailing list. If the major script engines are not complying with the spec, either the spec should change or the implementations should. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |