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 31 Dec 2009 20:14 Dr J R Stockton wrote: > the most important reader must be the writer, Utter nonsense. > the code as written is not necessarily the code as transmitted. Non sequitur. PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: Garrett Smith on 1 Jan 2010 03:30 Asen Bozhilov wrote: > Garrett Smith wrote: > >> Host Objects: >> * Operators: >> - DO not use delete operator with host object (IE Errors) > > That error can you see isn't only in IE. Try it code above in Firefox > 3.5: > > delete window.location; //Security error" code: "1000 OK, but Firefox, or Gecko implement that as a native JSObject with Object.prototype on the prototype chain. It is a little different in IE, where the object is not a JScript object. location.valueOf(); // Error in IE. location instanceof Object; // False in IE -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Dmitry A. Soshnikov on 1 Jan 2010 12:43 On Dec 31 2009, 11:23 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > Dmitry A. Soshnikov wrote: > > On Dec 30, 4:04 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > >> Dmitry A. Soshnikov wrote: > >>> 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. > >> Modifying the public interface of String changes Strings to be something > >> different. Any code that uses String now has that change. > > > Nope, it hasn't. Sorry, bug that's just a demagogy. The code will have > > that changes when it will *use* that changes. And please, show me, how > > many changes you'll need to do for modifying method name from e.g. > > `capitalize' to `capitalizeMethod', if that method uses in e.g. 10 > > files and doesn't matter where it is described - in > > `String.prototype.capitalize' or in > > `VeryOwnStringNamespace.capitalize' How many? Please count and tell > > me. So, please, do not use demagogy as the logical arguments. > > Given a piece of code M that has:- > > String.prototype.capitalize = 1; > > Another piece of code O that uses M now has capitalize method available. > > <script src="m.js"></script> > <script src="o.js"></script> > > So m.js creates a dependency from everything, to modification to > String.prototype. > > If m.js were to define something else:- > > M.capitalize= 1; > > - then the exact same problem occurs. I think this is what you were > getting at. > Yep. > >> Creating a separate file for string utils does not impose a global > >> change dependency. > > > Does. Absolutely the same. Take the example above - please count the > > changes you need - in *real* dependency - when some code *uses* that > > name: 'string'.capitalize() or VeryOwnStringNamespace.capitalize > > ('string'). > > A separate *file* would be depended on where it is included. > > <script src="p.js"></script> > <script src="o.js"></script> > > If p.js does not contain m.js (this could happen in a build), there > would be no dependency on M.capitalize. > > If m.js is an author file (not using a build tool), is not about > built-in String/String.prototype, and is about formatting strings, then > m is defining two things:- > 1) user defined string formatting > 2) built in String > > The user-defined String formatting routines could becomes properties of > one object, maybe stringFormat. That is clearly about one thing. > Unclear. You correctly mentioned that "the exact same problem occurs" with `String.prototype.capitalize' and `M.capitalize' in previous part. Now you're talking about some "build tool" which builds dependencies. What again difference do you see in that will "m.js" contain `String.prototype.capitalize' or `M.capitalize', please explain? Let me again to mention the real dependency (regardless some "build tools") - the dependency *is*, when some code uses that `.capitalize' method, regardless how was it described. If to take in mind you "build tool", I think augmenting of some built- in object you'd like to put in some "global/general/built-in/common -.js" which includes to *every* file. Meanwhile, "m.js" with own namespace `M' and method `M.capitalize' will be included only in needed files, right? Do I understand you correctly? Is this you want to tell me? If so, let me again to mention about real dependency - when code will *use* concrete and exact `.capitalize' method, regardless *including* by some "build tool". Moreover, nothing prevents to place `String.prototype.capitalize' also "m.js". > >> Putting the captilize function in a separate separates the concern so > >> that only as many modules as necessary depend on that module. > > > Nope, how can't you see - that the dependency is equal in case you're > > describing. > > A module that adds a property to something it doesn't own introduces > something globally accessible that unrelated to the module itself. It is > doing more than it should. It is not really modular. > First, not exactly "globally". Second, it's not the module who puts "something" into the "something". That *you* augment the built-in module with new functionality to make more readable and useful code (I remind, `String.prototype' is a module itself - so you put new functionality into it. But not "some module is doing more than it should"). > >> Modifying built-ins prototypes maximizes the dependency. > > > I've already described my meaning why augmenting of built-ins could be > > the issue - only if: > > > (a) augmenting Object.ptototype till we haven't control of {DontEnum}/ > > [[Enumerable]]. This point goes without saying. But when we'll have > > control of [[Enumerable]], I thinks it could be very useful. > > > (b) Using 3rd-party libs. But from this point of view - there's no > > difference, where to describe your objects. > > On this point, there is a huge difference where the object is defined. > If the client of the API defines String.prototype.capitalize, and the > library defines the same, there will be a conflict. > > The library new version could define `YourCompanyNameSpace`, but why > would it? > Not a huge - on practice, and equal on theory (why not for `YourCompanyNameSpace`?). And again, that exactly users of a library who will afraid and will not touch the `String.prototype' because they think that they depend on library (and new version of library may do everything). In other case users are independent from any library and can augment everything they want, right? And that's not a bad practice at all. > > (c) If some, using some augmented built-ins, will have a habit to use > > 'string'.capitalize(), he can be confused not founding this method in > > other project. But again - there's no difference which habit he has: > > 'string'.capitalize() or VeryOwnStringNamespace.capitalize() - there > > will be no such method in other project. Or, maybe just psychological > > difference - in case of 'string'.capitalize() user can think that it's > > really own method - but, that's problem of the user - he first should > > learn language on which he writes. > > On point (c), I see an issue with shared codebase; not necessarily > another project, per se, but elsewhere in the same application that is > using your module. > Yep, and it can be with any other own code shared anywhere, when some will have a habit to use it. I mentioned that exactly to show that there's no difference. > > So - the dependency is equal. > > With either VeryOwnStringNamespace.capitalize, or > String.prototype.capitalize, yes, they both introduce globally > accessible method where they are included. > Yep. > I want to look at Ext.util.Format.capitalize, then consider an > alterantive String.prototype.capitalize and compare alternatives. First > look at the Ext version. > > First off, the package `Ext.util.Format` is not specific. Is `Format` a > verb or a noun? `Format` as a noun would seem to be a constructor, so > it shouldn't be that. If Format is a verb, then is it a method? What > does `Format` format? Does it format HTML code? Dates? Numbers? > Templates? As lengthy as that namespace is, it does not describe string > formatting. Indeed, format seems in the verb sense here, but it is not a > method; it is an object. The object has methods that perform many types > of formatting. None of the methods have much to do with each other; > they're categorized to work with strings and return strings. Instead, I > would prefer to shorten that to have just:- > > Ext.formatString > Ext.formatHTML > Ext.formatDate > > I've reformatted `Ext.util.Format.capitalize` function to wrap: > > capitalize : function(value){ > return !value ? value : value.charAt(0).toUpperCase() + > value.substr(1).toLowerCase(); > } > > There are a few problems with that function. When passed a falsish > value, the value itself is returned. > > The non-standard substr method should be replaced with a call to the > standard String.prototype.substring. > > The method does not consider strings that begin with non-characters, > such as leading whitespace or tic marks. For example, If input is " > higiri" and it is desired to have the method return the first > non-whitespace to upper-case, so " Higiri". > > Here's a prototype'd version of Ext-js's "Ext.util.Format.capitalize": > > if(!String.prototype.capitalize) { // Should we add a safety check? > return this.charAt(0).toUpperCase() + this.substr(1).toLowerCase(); > > } > > Should there be a safety check? What if the safety check fails? > > What about a piece of code that has access to the change to > String.prototype.capitalize, and wants to change it? Is that okay to > redefine String.prototype.capitalize? Is capitalization in a certain way > something that all strings should have, and should the method name be > `capitalize`? > > Or what about: > > String.prototype.startsWith? > > What should that do? > > If startsWith does something that is purely related to a *String*, and > not how *your application* is *using* strings, then it may be a good > candidate for a Standard in ES Harmony. For example, > String.prototype.trim that was added in ES5. Perhaps > String.prototype.startsWith could be a candidate for ES6. > > If something is a good candidate for a Standard, then it is best to not > create a potential conflict. If ES6 defines String.prototype.startsWith, > but slightly differently, then the code that is defining > String.prototype.trim would want to avoid the safety check. It would > have to hide the built-in startsWith method and would want to avoid any > safety checks like:- > > // No good if it is defined (in ES6, etc) > if(!String.prototype.startsWith) { > > } > > An alternative is the code could instead redefine > String.prototype.startsWith to String.prototype.myVeryOwnStartsWith. > > But then we are getting to the point where the method name is trying > hard to have an identifier that identifies it as being something added > not built in. > > > Here you're describing something concrete and already regardless topic (it's not so interesting how `capitalize' is implemented in ExtJS or in Prototype.js, this method was taken only for an abstract example of augmenting) - is it a good or bad practice to augment built-ins. So I let myself to answer shortly - even regardless is a "good" or "bad" candidate for "some next Standard", it's absolutely not a bad practice from my point of view - if you understand what are you doing. That will let to write more clear and useful code. > >> Everything has > >> String.prototype, right? > > > Absolutely right. > > >> Well, now if you modify that, then everything > >> has that modification. > > > Of cause > > ... > Ok, I've "appreciated" this demagogy in this part of your answer ;) So, concluding this ('cause I don't wanna to make a useless dispute - I see what see, I know what I know), some questions I have to you: 1. Do you understand that your *statement* about augmentations of built-ins - is just your own (humble) opinion? (Actually, exactly the same as mine. But in difference from yours, mine doesn't forbid, but explain why it's good and when it can be the issue). Also, I'd like to mention, that firstly your statement sounded as "Don't modify objects you don't own". There you didn't talk about "built-ins" bug about abstract "not own" objects. Although, in our talk I found out that you mean also built-ins. For me, touching some *other* objects that I don't own (but not a built-ins) - is also can be useless practice (although, I don't use words "bad practice", 'cause even regarding not to built-ins but to some other - it could be useful to make some patch on some 3rd-party code, although, they can do it themselves in new version of library). 2. I'd like to hear how exactly your position sounds. I've already mentioned my position about this question: "I don't force anyone to augment built-ins, I don't spread this idea, I'm just not agree with the statement that augmenting of built-ins in dynamic language with mutable objects - is a bad practice. Again - it's normal practice and let to write more useful code against that long ugly as in ExtJS for `.capitalize'". So whatever you write (for whom this "Code Guidelines"?) - will you write it or not (that it's a "bad practice") - I don't mind. But if some using this "Code Guidelines" will (or will try to) judge anyone by that question (about augmenting of built-ins) - I'll tell again, that that people don't understand why they are judging so and they don't think with their own head. Also that will be a bad practice of using such "Code Guidelines" for *novices*, which will think that everything written there (in statement manner!) - is conclusive true. But it's not so. P.S.: Happy New Year ;) Regards. /ds
From: Dmitry A. Soshnikov on 1 Jan 2010 12:53 On Jan 1, 8:43 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: [snip] > > > >> Everything has > > >> String.prototype, right? > > > > Absolutely right. > > > >> Well, now if you modify that, then everything > > >> has that modification. > > > > Of cause > > > ... > > Ok, I've "appreciated" this demagogy in this part of your answer ;) > Sorry, Garrett I didn't see a half of your answer because of "read more >>" link (I didn't see it before here), so I thought you write only "Of cause and ...". I'll read the full your answer and will add some answer to mine previous. It wasn't your demagogy in this place, apologize. /ds
From: Garrett Smith on 1 Jan 2010 13:34
Dmitry A. Soshnikov wrote: > On Jan 1, 8:43 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> > wrote: > > [snip] > >>>>> Everything has >>>>> String.prototype, right? >>>> Absolutely right. >>>>> Well, now if you modify that, then everything >>>>> has that modification. >>>> Of cause >>> ... >> Ok, I've "appreciated" this demagogy in this part of your answer ;) >> > > Sorry, Garrett I didn't see a half of your answer because of "read > more >>" link (I didn't see it before here), so I thought you write > only "Of cause and ...". I'll read the full your answer and will add > some answer to mine previous. It wasn't your demagogy in this place, > apologize. > You're using Google Groups, then, I take it. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |