Code Guidelines
in [JavaScript]
|
Prev: Dynamic iframe caching problem workaround needed for Firefox
Next: JavaScript code mangler / scrambler / ... khm, more than obfuscator... :)
From: Dmitry A. Soshnikov on 3 Jan 2010 10:35 On 2 Ñнв, 03:13, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: [snip] > > Modifying String.prototype has some not so good consequences. They are: > (1) greater likelihood to conflict with something else than > YourOwn.stringFormat.capitalize. (a) future version of ES, (b) other > third party libs. (2) is less clear about where it is defined. > Ok, let's conclude it. I completely understand that reasons (moreover, with some of them I agree and mentioned myself). What I was saying to you in this thread regarding to augmenting of built-ins - is about *formulation* of the answer. Taking into account that it's your article (or whatever it is) - you can write as you wish including formulation such as "Don't touch/augment object that you don't own". Meanwhile, I suggested (and would write myself if it was my article) something like this: "Be careful augmenting/modifying objects that's you don't own. Although, you can do this e.g. augmenting some built-ins (for getting new needed functionality with more useful, logical and elegant code) take in mind several well-known issues, main of which are: (a) Augmenting Object.prototype because (here small explanation) and (b) Using some 3rd-party libs (here again small explanations)." Without saying is it a good or bad practice. > > Are there any good reasons for modifying the built-ins? > I've told, from functionality point of view - actually, there's no difference where will you put this code. But the main reasons for me to write 'string.capitalize()' instead of YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize () is: - logical place for string's methods in string module (and I'll prefer to put this functionality into the already existing module *taking into account all issues I'll have (if I will)); - more useful and elegant code (in OOP-style instead of procedure- style). And please keep in mind, I'm not asking you may I write so or not, 'cause I repeat - I understand what I'm doing and why I'm doing so and moreover, still repeat, that's just your own opinion with your own issues (yeah, I understand that you'll always afraid that ES will (or will not?) provide tomorrow (after several years) new method `capitalize' in `String.prototype' and you understanding that will use YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize () for that. Meanwhile me, understanding what that's all about and why do I need this - will augment `String.prototype' with `capitalize' and will use it. When after 5 years ES will provide the same method (and I guess it will have similar functionality - just like with `trim' which people use not the first year) - I'll use built-in method). /ds
From: Jorge on 3 Jan 2010 19:26 On Jan 3, 4:35 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > (...) > And please keep in mind, I'm not asking you may I write so or not, > 'cause I repeat - I understand what I'm doing and why I'm doing so and > moreover, still repeat, that's just your own opinion with your own > issues (yeah, I understand that you'll always afraid that ES will (or > will not?) provide tomorrow (after several years) new method > `capitalize' in `String.prototype' and you understanding that will > use > YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capita lize > () for that. Meanwhile me, understanding what that's all about and why > do I need this - will augment `String.prototype' with `capitalize' and > will use it. When after 5 years ES will provide the same method (and I > guess it will have similar functionality - just like with `trim' which > people use not the first year) - I'll use built-in method). There at least a couple of ways to avoid that situation : 1st.- Don't use a generic name such as "capitalize", use instead: String.prototype.dmitrySoshnikovsCapitalize= function () { .. }; 2nd.- Don't hard-code the name, do an indirection instead. For example: String.prototype[myApp.capitalize]= myApp.capitalizeFunction; And then use "a string"[myApp.capitalize](); //Access indirectly. 3rd and best.- Get real. Forget about this until it actually becomes a problem, if ever. -- Jorge.
From: Garrett Smith on 3 Jan 2010 23:01 Dmitry A. Soshnikov wrote: > On Jan 1, 9:34 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> Dmitry A. Soshnikov wrote: >>> On Jan 1, 8:43 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> >>> wrote: >>> [snip] [...] >> You're using Google Groups, then, I take it. >> -- >> Garrett >> comp.lang.javascript FAQ:http://jibbering.com/faq/ > > Yes I use Google Groups to see/answer. And what do you? > I use Thunderbird and eternal-september.org news server. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 4 Jan 2010 00:26 Dmitry A. Soshnikov wrote: > On 2 янв, 03:13, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > > [snip] >> Modifying String.prototype has some not so good consequences. They are: >> (1) greater likelihood to conflict with something else than >> YourOwn.stringFormat.capitalize. (a) future version of ES, (b) other >> third party libs. (2) is less clear about where it is defined. >> > > Ok, let's conclude it. I completely understand that reasons (moreover, > with some of them I agree and mentioned myself). > > What I was saying to you in this thread regarding to augmenting of > built-ins - is about *formulation* of the answer. Taking into account > that it's your article (or whatever it is) - you can write as you wish > including formulation such as "Don't touch/augment object that you > don't own". > I am writing a Code Guidelines document. It is important for that contents to be accurate and relevant. > Meanwhile, I suggested (and would write myself if it was my article) > something like this: > > "Be careful augmenting/modifying objects that's you don't own. > Although, you can do this e.g. augmenting some built-ins (for getting > new needed functionality with more useful, logical and elegant code) > take in mind several well-known issues, main of which are: (a) > Augmenting Object.prototype because (here small explanation) and (b) > Using some 3rd-party libs (here again small explanations)." > > Without saying is it a good or bad practice. > The Code Guidelines document is for code reviews. Design advice for code reviews might want to provide an alternative suggestion and explain consequences for the design. >> Are there any good reasons for modifying the built-ins? >> > > I've told, from functionality point of view - actually, there's no > difference where will you put this code. But the main reasons for me > to write 'string.capitalize()' instead of > YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize > () is: > DOn't you think you're exaggerating the namespace typing issue just a *little*? Not even Qooxdoo and Ext have such long namespaces. [...] > - more useful and elegant code (in OOP-style instead of procedure- > style). > How is it more "OOP" than defining a separate method on your own namespace? [...] > use > YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize > () for that. Meanwhile me, understanding what that's all about and why > do I need this - will augment `String.prototype' with `capitalize' and > will use it. When after 5 years ES will provide the same method (and I > guess it will have similar functionality - just like with `trim' which > people use not the first year) - I'll use built-in method). > Is the `captitalize` method related directly to strings, or is it about formatting? Are there other types of formatting routines that may be used in conjunction with that? -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Dmitry A. Soshnikov on 5 Jan 2010 05:11
On 4 Ñнв, 03:26, Jorge <jo...(a)jorgechamorro.com> wrote: > On Jan 3, 4:35 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> > wrote: > > > (...) > > And please keep in mind, I'm not asking you may I write so or not, > > 'cause I repeat - I understand what I'm doing and why I'm doing so and > > moreover, still repeat, that's just your own opinion with your own > > issues (yeah, I understand that you'll always afraid that ES will (or > > will not?) provide tomorrow (after several years) new method > > `capitalize' in `String.prototype' and  you understanding that will > > use > > YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capita lize > > () for that. Meanwhile me, understanding what that's all about and why > > do I need this - will augment `String.prototype' with `capitalize' and > > will use it. When after 5 years ES will provide the same method (and I > > guess it will have similar functionality - just like with `trim' which > > people use not the first year) - I'll use built-in method). > > There at least a couple of ways to avoid that situation : > > 1st.- Don't use a generic name such as "capitalize", use instead: > String.prototype.dmitrySoshnikovsCapitalize= function () { .. }; > Yeah, funny ;) > 2nd.- Don't hard-code the name, do an indirection instead. For > example: > String.prototype[myApp.capitalize]= myApp.capitalizeFunction; > > And then use "a string"[myApp.capitalize](); //Access indirectly. > Yep, the sickness which is called "softcode" - when some afraid of hardcode and see hardcode everywhere. Also funny, I don't wanna support such code :) > 3rd and best.- Get real. Forget about this until it actually becomes a > problem, if ever. > Yep, I think so too. P.S.: You forgot the 4th - YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capita lize() :) Let's fill the code with that long lines and give for supporting to somebody, he will be glad ;) /ds |