Code Guidelines
in [JavaScript]
|
Prev: Dynamic iframe caching problem workaround needed for Firefox
Next: JavaScript code mangler / scrambler / ... khm, more than obfuscator... :)
From: Thomas 'PointedEars' Lahn on 27 Dec 2009 20:04 David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >> > Thomas 'PointedEars' Lahn wrote: >> >> David Mark wrote: >> >> > RobG wrote: >> >> >> Garrett Smith wrote: >> >> >> > Replace: "</" + "script>" >> >> >> > with: "<\/script>"; >> >> >> > Replace: "</td>"; >> >> >> > with: "<\/td>"; >> >> >> >> >> >> I don't understand the issue here, is it specifically with the TD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> >> end tag? Or is it more generally with end tags in HTML sent as an ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> >> XHR response? >> >> > No, it refers to markup in script (e.g. document.write calls). >> >> [...] >> >> > Nothing to do with the tag type. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> The *what*? I thought this was comp.lang.javascript, not >> >> alt.scriptkiddie.misc. >> > The type of tag serialized in the string (e.g. TD vs. SCRIPT). Are ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^ >> > you proposing to refer to these as *elements*? >> TD is one *element* type, SCRIPT is another. >> >> <http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.1> > > Are you kidding? No. Have you read that part of the Specification carefully? >> > I think not as we are talking about just one (ending) tag (not both). >> Iff you had meant "tag type" to distinguish between start tags and *end* >> tags, which AIUI you have not, then that would have been acceptable. > > As you understand what? You were referring to TD and SCRIPT as different "type(s) of tag". > Was my explanation unclear? It was not only unclear, it was incorrect. HTH PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: David Mark on 27 Dec 2009 22:06 On Dec 27, 8:04 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > David Mark wrote: > > Thomas 'PointedEars' Lahn wrote: > >> David Mark wrote: > >> > Thomas 'PointedEars' Lahn wrote: > >> >> David Mark wrote: > >> >> > RobG wrote: > >> >> >> Garrett Smith wrote: > >> >> >> > Replace: "</" + "script>" > >> >> >> > with: "<\/script>"; > >> >> >> > Replace: "</td>"; > >> >> >> > with: "<\/td>"; > > >> >> >> I don't understand the issue here, is it specifically with the TD > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>> >> >> end tag? Or is it more generally with end tags in HTML sent as an > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>> >> >> XHR response? > >> >> > No, it refers to markup in script (e.g. document.write calls). > >> >> [...] > >> >> > Nothing to do with the tag type. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>> >> The *what*? I thought this was comp.lang.javascript, not > >> >> alt.scriptkiddie.misc. > >> > The type of tag serialized in the string (e.g. TD vs. SCRIPT). Are > > ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^ > > >> > you proposing to refer to these as *elements*? > >> TD is one *element* type, SCRIPT is another. > > >> <http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.1> > > > Are you kidding? > > No. Have you read that part of the Specification carefully? No need. > > >> > I think not as we are talking about just one (ending) tag (not both).. > >> Iff you had meant "tag type" to distinguish between start tags and *end* > >> tags, which AIUI you have not, then that would have been acceptable. > > > As you understand what? > > You were referring to TD and SCRIPT as different "type(s) of tag". You misunderstand. They are different "types of tags" (as only the ending tags of each are present in the serialization). If I had meant element, I should have said element. :)
From: Garrett Smith on 28 Dec 2009 00:25 Asen Bozhilov wrote: > Dmitry A. Soshnikov wrote: > >> If you still wanna to write this as a rule, please mentioned, that >> it's not the rule, but *just your own suggestion and own meaning*, >> meanwhile other people can choose different (good) way augmenting >> object and write in OOP-style such as `string.capitalize()' instead of >> long ugly `Ext.util.Format.capitalize(string)'. Especially in own >> project. > > You are absolutely right, but augmentation Object.prototype can be > harmful and confused. If implementations use native object produced > via `new Object()` as a VO and internal [[Prototype]] refer > Object.prototype, any augmentation of `object' referred from > Object.prototype can be harmful and confused. See below: > > Object.prototype.x = 10; > var x = null; > (function() > { > window.alert(x); > }()); ......^ Move that paren inwards, to group the FunctionExpression, as: (function(){})(); > > 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]]. The prototype of teh global object is implementation-dependent. In Blackberry9000, the activation object has a [[Prototype]]. That is a severe bug. The identifier - x - would be resolved on Object.prototype when the scope chain was augmented "as if by the expression new Object()". The three cases where this happens:- 1) FunctionExpression with Identifier (NFE) 2) catch clause 3) - with - statement. (function(){ Object.prototype.x = 10; var x = null; with( 1 ) { alert( "with, x: " + x ); } try { throw.1; } catch(ex) { alert( "with, x: " + x ); } })(); The issue with NFE and catch clause was observable in Firefox up until around version 3.1. Firefox 3.5:- "with, x: 10" "catch, x: null" -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 28 Dec 2009 01:25 Dmitry A. Soshnikov wrote: > On Dec 27, 10:45 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > > [snip] > >> A public library that modifies >> the built-ins can't really be trusted to work with other code. >> > > I understand, and told myself, that's this is the only (again - the > only.) reason. And from this point of view, you should mention this > just as a warning for authors of libraries, but not as a rule for > programming on ECMAScript. > [...] What I have as draft includes most of what I wrote in the last message. The advice to create a top-level function advise creating a method as a member of the global object, having the same problems. Instead, a separate interface should be created. The interface should be clearly defined, cohesive, and unlikely to conflict with other objects that use the system. > >>> So, again, it's absolutely normal to augmenting objects in ES, >>> providing good documentation of what have you augmented (and for whole >>> code in general). >>> If you still wanna to write this as a rule, please mentioned, that >>> it's not the rule, but *just your own suggestion and own meaning*, >>> meanwhile other people can choose different (good) way augmenting >>> object and write in OOP-style such as `string.capitalize()' instead of >>> long ugly `Ext.util.Format.capitalize(string)'. Especially in own >>> project. You can do that, but it doesn't fit what I think of as OOP. It is an abstraction using inheritance, but it lacks encapsulation and modularity. It is more like a reverse-inheritance type of scheme that changes String in a way that may or may not be forwards-compatible. Object.create, for a coincidental example, is now a built-in method, but exists as a user-defined method in some codebases. >> I do not agree that util is a good name for a package. Packages or units >> of code should be organized by usage pattern. >> >> "util" is a kitchen sink. >> > > That's not mine, that's real example from ExtJS library. I mentioned > that to show how the code can converts into the overloaded massive > long lines using everywhere things such as procedure-like style > `Ext.util.Format.capitalize(string)'. Yeah, influence of Java is > conclusive in ExtJS library ;) > Util is not a descriptive package name. Not for Java, and not for Ext.js. Take a look at java.util and please tell me Date have to do with Arrays or TimerTask? Nothing, right? Well javascript borrowed from Java, too. We've got the poor Date class and Math. Many of the Math properties could have been moved to Number and/or Number.prototype, depending on the property. Math.floor could be Number.prototype.floor(), We could have 3.45.round() instead of Math.round(3.45). Number.PI, Number.max(10, 11, 12). Well that is all fiction made up but for me it makes way more sense than having a separated Math class. It seems worth considering changing that to Ext.string, and adding the capitalize method to it. Ext.string.capitalize("foo"); Collisions to that would be deliberate and you would know right off what the capitalize method is, where it is defined, and not have to worry who buggered String.prototype or if the buggering was a dual- action effort on part of multiple third party libraries. The capitalize method would not localize consistently, as noted recently on ES-Discuss[1]. If the string is translated and included literally, this doesn't occur. var msg = "${req.msg}"; In ES5, a property can be defined has having [[Writable]] = false. This can happen in Object.create, with Object.defineProperty, setting writable: false. Object.freeze seals an object and makes its properties unmodifiable by setting [[Writable]] to false. Creating a sealed object eliminates the possibility for conflicts with another Ext.string.capitalize. [1]https://mail.mozilla.org/pipermail/es-discuss/2009-December/010482.html -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Dmitry A. Soshnikov on 28 Dec 2009 04:49
On Dec 28, 9:25 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > Dmitry A. Soshnikov wrote: > > On Dec 27, 10:45 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > > > [snip] > > >> A public library that modifies > >> the built-ins can't really be trusted to work with other code. > > > I understand, and told myself, that's this is the only (again - the > > only.) reason. And from this point of view, you should mention this > > just as a warning for authors of libraries, but not as a rule for > > programming on ECMAScript. > > [...] > > What I have as draft includes most of what I wrote in the last message. > The advice to create a top-level function advise creating a method as a > member of the global object, having the same problems. > > Instead, a separate interface should be created. The interface should be > clearly defined, cohesive, and unlikely to conflict with other objects > that use the system. > Formally, there's no full protected "interface" from this point of view. Will you name it `MyVeryOwnNamespace', and tomorrow, the same name will be in all `libraries' and in ES itself. So, naming collisions should not be treated as the main reason. > > > >>> So, again, it's absolutely normal to augmenting objects in ES, > >>> providing good documentation of what have you augmented (and for whole > >>> code in general). > >>> If you still wanna to write this as a rule, please mentioned, that > >>> it's not the rule, but *just your own suggestion and own meaning*, > >>> meanwhile other people can choose different (good) way augmenting > >>> object and write in OOP-style such as `string.capitalize()' instead of > >>> long ugly `Ext.util.Format.capitalize(string)'. Especially in own > >>> project. > > You can do that, but it doesn't fit what I think of as OOP. It is an > abstraction using inheritance, but it lacks encapsulation and modularity. > What exactly do you mean? Please explain. > It is more like a reverse-inheritance type of scheme that changes String > in a way that may or may not be forwards-compatible. Object.create, for > a coincidental example, is now a built-in method, but exists as a > user-defined method in some codebases. > > >> I do not agree that util is a good name for a package. Packages or units > >> of code should be organized by usage pattern. > > >> "util" is a kitchen sink. > > > That's not mine, that's real example from ExtJS library. I mentioned > > that to show how the code can converts into the overloaded massive > > long lines using everywhere things such as procedure-like style > > `Ext.util.Format.capitalize(string)'. Yeah, influence of Java is > > conclusive in ExtJS library ;) > > Util is not a descriptive package name. > > Not for Java, and not for Ext.js. > > Take a look at java.util and please tell me Date have to do with Arrays > or TimerTask? Nothing, right? > > Well javascript borrowed from Java, too. We've got the poor Date class > and Math. Many of the Math properties could have been moved to Number > and/or Number.prototype, depending on the property. Math.floor could be > Number.prototype.floor(), We could have 3.45.round() instead of > Math.round(3.45). Number.PI, Number.max(10, 11, 12). Well that is all > fiction made up but for me it makes way more sense than having a > separated Math class. > Yeah, it could easily be `3.45.round()' instead of `Math' I agree. > It seems worth considering changing that to Ext.string, and adding the > capitalize method to it. > > Ext.string.capitalize("foo"); > > Collisions to that would be deliberate and you would know right off what > the capitalize method is, where it is defined, and not have to worry who > buggered String.prototype or if the buggering was a dual- action effort > on part of multiple third party libraries. > But there's no difference, will somebody put `capitalize' into the `String.prototype' or will define own `Ext' or `Ext.string' namespace - tomorrow, it can easily appear in all other libraries and in ES itself. So, don't use name collision as a reason. Moreover, I tell, people which use libraries think vice versa - they think: "we don't not modify String.prototype as we're using 3rd-party frameword, which can put tomorrow (in the next version) `capitalize' method into it. So let's make our own namespace such as OutSuperDuperNamespace.string and put `capitalize' there." And tomorrow, OMG, that framework provides the same `OutSuperDuperNamespace' and even `OutSuperDuperNamespace.string' breaking down all the project. So, that's not the reason. > The capitalize method would not localize consistently, as noted recently > on ES-Discuss[1]. If the string is translated and included literally, > this doesn't occur. > I understand, but that's completely another question, and doesn't touch the discussing topic. > > In ES5, a property can be defined has having [[Writable]] = false. > > This can happen in Object.create, with Object.defineProperty, setting > writable: false. > > Object.freeze seals an object and makes its properties unmodifiable by > setting [[Writable]] to false. > > Creating a sealed object eliminates the possibility for conflicts with > another Ext.string.capitalize. > Yep, thanks, I've also read ES-5 spec already. So, you're moving to the way I told - better to suggest to use some static language in such case, but not the language with dynamic mutable objects and statement as a rule: "Do not touch your own objects". So, if you'll write something like: "Remember that augmenting built- ins may cause naming conflicts, bla-bla... but the same can be with any other name in the program - no matter where it's - in global or in own namespace" - that's will be normal. It will sound like suggesting from your own opinion. But if you'll write - "Augmenting built-ins - is a bad practice" - that will be categorical and wrong, and I can statement, that person which spread that not completely understand the goal of dynamic languages (I do not mean exactly you, I'm telling abstractly now). /ds |