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 7 Jan 2010 17:34 Dmitry A. Soshnikov wrote: > On 7 янв, 09:59, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > > [snip already discussed not once things] > >> Full power?` > > I meant when you can you system with all its features without limiting > yourself with some invariant inflexible patterns which force you to > write in a way of some other languages > What is inflexible about creating your own object? It is trivial to do that, most times. > Yeah, I've heard your argument that authors of some languages such as > ECMAScript, Ruby, etc. make this ability to write useful elegant code > augmenting built-ins with new functionality just as a big and > understandable mistake. Right? > Did I say mention a mistake in the design of the language? > But I tell you – no, it's not. It's special useful ability to do so if > you're free from well-known issues related to it. > I've read that again a few times. The language lets you do a lot of things. Many of them are not useful. Some of them are powerful and sometimes dangerous. > And you – just haven't even rights to tell in tone in your document as > "Don't touch!" Who are you to talk in this tone? > What tone? > [snip] > >> Again with the full power. > > I've already explained. Again – that mean when you completely know the > system (the language) and able to use all its features specially > designed for that. > >> Design decisions should be based on pros and cons; not some absolute >> ideal of how the author would have redesigned some other piece of code. >> > > Sure, but you don't see that specially designed feature with > augmenting objects (any object and especially built-ins) - is also > pros. > When do I get to hear those? I've been waiting for a lot of messages and losing patience. > Your argument "you just like it, it's not logical argument" which > you're continue to use seems really don't understand that that "like" > – is the feature which was specially designed. To use this feature or > not – that's only your decision which maybe based on a habit from > languages such as C++ or Java. > Great. Show me a *good* example of doing that and we'll see an exception to the rule. Notice, I did not say there were no exceptions to the rule, but that you've not yet shown an example of that. The `capitalize` example was a start, but then you started in with asking me if I can think abstractly. > Though, e.g. in Python it's impossible to augment built-ins, but still > possible to dynamically augment any other user-defined objects (but > you against any augmentation of any objects that you don't own, so > that's also is not your case). > >> Objects can talk to each other but should not be modifying each other. > > That's other thing and pattern of programming and is not related to > dynamic properties definition. > >> YUI calls it "augmentObject", I call >> it "mixin". Either name is fine by me, really it is obvious enough. >> >> var AB = APE.mixin(A, B); >> > > Yep, I also use term "mixin". > >> That way I've created an object dynamically, not statically. But notice >> that I am not saying something like: >> >> A.js: >> >> function A(){ >> >> } >> >> B.prototype.ddd = function(){ >> //lets fix this buggy method. >> this.ddd = Math.abs(this.d); >> >> }; >> >> A.prototype = new B; >> >> Oh, now the same problem as with TableRenderer, I've just created a >> dependency cycle. NOw B depends on A. F. >> > > Because of "A.prototype = new B;"? > No, that's bad, but not my point. I used that because it was the simplest way to show inheritance. > If you use Math.abs(...) – no everything depends on Math? Right. But > maybe do not program at all in this case? > RIght, A.js has modifications to the B object. Now, when B is used, it gets those modifications. A depends on B because A extends B and now B depends on A because A extended B. This sort of thing can sometimes be even advocated as "Best Practice". talk about "demagogy". Here is a great example of a very problematic reverse inheritance: http://www.dustindiaz.com/new-in-javascript/ The problems you'll see are similar, though instead of the "subclass" modifying the super, we have the instantiation of the constructor, or `nue`, modifying the prototype. Here's an example: // DO NOT USE THIS CODE. | // Copyright Dustin Diaz | function nue (f) { | var args = [].slice.call(arguments, 1); | f.prototype.constructor = f; | f.apply(f.prototype, args); | return f.prototype; | } | | function X(a){ | if(typeof a == "number") | this.a = a; | } | | var x1 = nue(X), | z1a = x1.a; | var x2a = nue(X, 1).a; | | [x1a, x1.a] Results: [undefined, 1] THe problem is caused by `nue` modifying x.prototype. Dustin Diaz accepts none of the criticism and happily continues in his telling Grey he is wrong, while Grey and Isaac are correct. >>> You found out for yourself some pattern which is based on some >>> understandable issues. You then wanna to collect some rules and use >>> such pattern thinking that now you are free from issues and problems. >> Why not? >> > > No, that's OK, until you start think that you think out something the > one and only which is thought inflexible and start to describe it in > tone like "Don't touch". > IF you want to touch it, then that would be an exception to the guideline. I'm not saying that doesn't exist, but I haven't seen your example of that. > I repeat, in system which I know and completely control (I don't > augment Object.prototype, I don't use 3rd-party libs), it's very > useful ability designed by the author of the language – to use new > functionality directly on object – that's elegant and useful. And yeah > – sure it's the main argument of such feature, and exactly with that > argument it was designed, so please don't use that argument ("you just > like it") against me, k? ;) You can continue to write in a way of > Pascal or C++ or Java or whatever. Yeah, programming on Ruby is also > is counter-indicative to you – there also augmentation of built-ins > (as additional modules) is often used. > Why do you want to modify built-ins' or other objects? > [snip useless parts of talk] > >> If you want to make a real argument, going from abstraction to >> concretion, we can see an example. We have already seen the example with >> Crockford's buggy `String.prototype.trim`. > > I don't mind with Crockford's buggy `String.prototype.trim`. > > Please answer, which problems will I have if I: > > (a) had own implementation of '.trim' and used it as ' string '.trim() > (b) then switch to built-in implementation and use it in the same way > The only problem in that particular usage pattern is a minor performance penalty. Why would you want to use a hand-rolled version that doesn't behave as standard? > Why do you still continue spread some strange case when some > (ostensibly) want to overwrite built-in implementation with own? > That's again demagogy (yes, again). > What strange case? String.prototype.trim side effects? That is only manifestation of one problem of the two types of problems. The other manifestations of that problem are conflict with other code doing the same, and the other problem is it's not clear which code (or object) owns String.prototype ("where is that change coming from?"). > [snip the same; discussed not once alreay] > >> Wrong design? No, not right or wrong. I tend to more think in terms of >> actions and consequences. >> > > Sure, and which consequences will I have in system I fully know and > control (for you that means: I don't augment Object.prototype and > don't use 3rd-party libs)? For what reason I should limit myself and > do not use useful and elegant feature provided by the author of the > language as a part of its ideology? > What ideology? The problems have been explained and snipped and I'm done with typing again and again. >> Saying "I know what I'm doing" while ignoring the known consequences > > Who is here ignoring the known consequences? You. Crockford. Probably others. Should I repeat again > that I know and understand all that consequences? But in system I > fully know (and don't afraid of it) and control (you should read this > as: I don't augment Object.prototype and don't use 3rd-party libs) – > for what reason I should limit myself and do not use useful and > elegant feature provided by the author of the language as a part of > its ideology (yeah, I copy-pasted it from previous sentence). > >> Is it difficult to use your own objects and not modify the built-ins? > > What do you mean "difficult"? I do not understand the obsession with buggering String.prototype. What do do that for? How do you think for what authors of > languages such as ECMAScript or Ruby or any else provided such > feature? Sure this elegant and useful (and logical – method/properties > of strings I can but into the String.prototype – the place specially > marked for it) syntactic sugar which is *specially* provided by the > authors. Why did the author do that? I don't know. I could guess or ask. Either way it doesn't matter what Brendan's ideology is, does it? And again repeat – from the functionality viewpoint there's > no difference – that's your choice to write in procedural style, but > the authors decided to make such useful sugar which is really elegant > and which is really pros from this viewpoint. For what reason I > should limit myself and do not use useful and elegant feature provided > by the author of the language as a part of its ideology (yeah, I copy- > pasted it from previous sentence). > >> No, we've established that it is not difficult. > > I don't understand why should we talk in manner – "is it difficult to > you do not use it and do it in a way I think out and think that this > is the one and only way. Yeah, I understand that it doesn't use > special feature of dynamic augmentation of built-ins and moreover I > believe it as a language and design mistake, but help me to fill > myself protected and leave my fear. So, please, don't do it... No, not > like this... Like this: Don't do it! Don't touch! It's difficult, > right? Don't do it." > I have no idea what your point is. >> The only remaining >> problem is that you like seeing "foo".capitalize. > > The "problem"? Why do you call it so? It's called useful and specially > designed feature of some well-known dynamic based language with > possibility mix in new functionality (in Ruby by the way, this term > "mixin" – is official). > >> What is the good reason for >> redefining the language to your deviations? > > But who ever said this? I let myself to copy-paste again from previous > sentence: > > (a) had own implementation of '.trim' and used it as ' string '.trim() > (b) then switch to built-in implementation and use it in the same way > > Why do you still continue spread some strange case when some > (ostensibly) want to overwrite built-in implementation with own? > That's again demagogy (yes, again). > Why do yo want to replace built-in function with your own? The only good reason for doing that, AFAIC, is if the feature is buggy, and then, doing it only after a feature test that verifies the implementation does not match the specification. > >> Any justificaiton for doing >> that would > > Actually I don't see any reason to do so, even without any > justification. But with that I didn't say a word about such case. > >> What is equal? Do you know what a dependency cycle is? > > Be sure. > >> I explained a >> situation > > The situation when some overwrite built-ins existing functionality > with own one? I didn't mean this – see again example with 'trim' (what > exactly did I mean). If you want to exactly *fix* some bug – this is > completely on your conscience when and how will you make (if ever) it. > If the system is uncontrollable, how can you program it? When > functionality of Format in your example will change, you can change it > in the same way (or remove if not needed) in your widget. But I meant > not that. > >> A bunch of nonsense there. > > Specially. > >> That is not what I argued. It is thoughtless, invalid code, written in >> what would appear to be global context, and will result in SyntaxError >> because of calling undefined identifier `If`, and having a misplaced >> `else` block. >> > > That's I've told – you see and analyze some tops, but should see > deeply. This syntax errors are completely not about the topic and you > use it (and mention) specially to show what the nonsense I write, > which means – maybe I even don't know the language on the level of > syntax errors, right? ;) Do you like it or not, but it's called direct > "demagogy" (and yes – again) ;) > > About the "If" – I used Microsoft Word This is seeming like a more and more of a waste of time. when was answering that time, > so it maybe it was converted automatically, don't know. But even that > doesn't justify your demagogy, sorry. > >> I didn't see you're solution. (the code you repeated 10x or so, with >> invalid syntax is irrelevant). >> > > Yeah, get the 10 points for mentioning invalid syntax ;) > I'm done here. You've got 0 rational argument, post some long code that I didn't write to try and say that long code is bad, then justify your design decisions on that basis, but with no other reasons. [..] -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Jorge on 7 Jan 2010 22:21 On Jan 7, 11:34 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > Dmitry A. Soshnikov wrote: > (...) > > Who is here ignoring the known consequences? > > You. Crockford. Probably others. Smith, you're as funny as a clown. -- Jorge.
From: Dmitry A. Soshnikov on 8 Jan 2010 16:27 On Jan 8, 1:34 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: [snip useless (talk === demagogy)] > Why do you want to modify built-ins' or other objects? Maybe want, maybe not - by situation. And if, then because of ideology (come on, you should again ask: "What ideology?" - well, try to think and understand it, if will be hard, please ask, I explain completely, though, I've already explained) and because of that it's useful syntactic sugar which is provided by the authors. I can do that, or cannot - by situation. In one project when I have own framework - I can do everything (including simply augmentation of the built-ins), in other project (e.g. the current one, when ExtJS is used) - we don't modify built-ins because ExtJS can do it also (although, ExtJS does it in a strange way - something it does augmenting built-ins, something - in own deep namspace). Technically there's no difference: capitalize(string); or string.capitalize(); Moreover, `capitalize(string)' is shorter on one dot - ".", but it's not your case ;) Thought, even technically `string.capitalize()' in theory should be resolved faster than global `capitalize(string)' and in own deep namespace such as `Ext.util.Format.capitalize()'. > > Please answer, which problems will I have if I: > > > (a) had own implementation of .trim' and used it as string '.trim() > > (b) then switch to built-in implementation and use it in the same way > > The only problem in that particular usage pattern is a minor performance > penalty. > Excuse me? Did I understand correctly that you said that new built-in implementation will have minor performance when I switch on it from the own `trim' implementation that I used before? Or it's just already trolling is started (not even demagogy)? > Why would you want to use a hand-rolled version that doesn't behave as > standard? > I don't understand again - is it trolling or is it kind of "privileged" humor? Did I understand correctly that you switch my (b) and (a)? For what? If I've told - first (a), then (b). [snip useless talk] > > Who is here ignoring the known consequences? > > You. Crockford. Probably others. Excuse me? [snip useless talk] > Why do yo want to replace built-in function with your own? I can't believe this (that's already not even funny ;), so no points for you). It's already trolling but not demagogy. Again (please pay maximum attention now and include your brain) - first (a), then (b), but not the vice versa, ok? Good. [snip useless talk] > This is seeming like a more and more of a waste of time. Yes, by the truth I've already mentioned that and wanted to conclude this talk. > You've got 0 rational argument Ok, take a cookie (or cracker), you have deserved it. And yeah, learn ECMAScript and its ideology and don't limit yourself with invariant inflexible patterns which force you to write in ideology of Java. Be flexible and use the language Dixi. You are free with your document. You can sit and entertain yourself with this document. You don't really think that some "code reviewers" (Gee, you're guys looking for me, right? ;)) can judge me and say any word about professional code if I'll augment built-ins in own project, right? Good then. Dixi. The talk is over. Good luck. /ds
From: Garrett Smith on 8 Jan 2010 18:18 Dmitry A. Soshnikov wrote: > On Jan 8, 1:34 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > > [snip useless (talk === demagogy)] > >> Why do you want to modify built-ins' or other objects? > > Maybe want, maybe not - by situation. And if, then because of ideology > (come on, you should again ask: "What ideology?" - well, try to think > and understand it, if will be hard, please ask, I explain completely, > though, I've already explained) and because of that it's useful > syntactic sugar which is provided by the authors. > > I can do that, or cannot - by situation. In one project when I have > own framework - I can do everything (including simply augmentation of > the built-ins), in other project (e.g. the current one, when ExtJS is > used) - we don't modify built-ins because ExtJS can do it also > (although, ExtJS does it in a strange way - something it does > augmenting built-ins, something - in own deep namspace). > > Technically there's no difference: > > capitalize(string); > > or > > string.capitalize(); > > Moreover, `capitalize(string)' is shorter on one dot - ".", but it's > not your case ;) > > Thought, even technically `string.capitalize()' in theory should be > resolved faster than global `capitalize(string)' and in own deep > namespace such as `Ext.util.Format.capitalize()'. > >>> Please answer, which problems will I have if I: >>> (a) had own implementation of �.trim' and used it as � string '.trim() >>> (b) then switch to built-in implementation and use it in the same way >> The only problem in that particular usage pattern is a minor performance >> penalty. >> > > Excuse me? Did I understand correctly that you said that new built-in > implementation will have minor performance when I switch on it from > the own `trim' implementation that I used before? Or it's just already > trolling is started (not even demagogy)? > I take you have believe that your hand-rolled trim will not be slower than native trim. That would be a very inefficient native implementation, to perform slower, no? Did you test your beliefs? Fine; I guess you did not test, but believe like everything else that you are ultimately correct. I set up a test case. Not all readers will have the foresight to see potential problems of modifying foreign objects. However, most should be able to compare two times and determine that the larger time means slower performance. I've set up a test function that uses your hand-rolled "trim" method renamed to "dcTrim" and compared the performance of that method (as `String.prototype.dcTrim`), to native `trim` (`String.prototype.trim`). // Your (Crockford's) hand-rolled function. String.prototype.dcTrim = function(){ return this.replace(/^\s+|\s+$/g, ""); }; // Names of trim functions to test. var trimNames = ["trim", "dcTrim"]; /* Accepts a name of a function to use for trimming, as in: * stringArray[0][trimName](); * and logs the result to the console. */ function testTrim(trimName){ // populate an array of strings var data = [], LEN = 1000000; data.length = LEN; // Populate an array of data with unique strings that need trimming. for(var i = 0; i < LEN; i++) { data[i] = " \t \t new test " + (Math.random() * i) + " \t \t "; } // Trim the strings in the data. var startTime = +new Date; for(i = 0; i < LEN; i++) { data[i] = data[i][trimName](); } var totalTime = new Date-startTime; // end time. // Get the next test in trimNames. var next = trimNames.pop(); console.log(trimName + ": " + totalTime); if(next) setTimeout("testTrim('" + next + "')", 500); }; void setTimeout("testTrim('" + trimNames.pop()+ "')", 500); Results in Firefox 3.5: dcTrim: 7027 trim: 2307 The native the user-defined "dcTrim" performed three times slower. Since you won't normally trim that many strings, you won't be saving 5 seconds. That is why I fairly called it a "minor performance penalty". I think it's clear now that your name calling (troll) is either very short-sighted or is a desperate attempt to win the argument (so much for the "truth"). >> Why would you want to use a hand-rolled version that doesn't behave as >> standard? >> > > I don't understand again - is it trolling or is it kind of > "privileged" humor? Did I understand correctly that you switch my (b) > and (a)? For what? If I've told - first (a), then (b). > I've asked for your motivation of why you prefer using a hand-rolled trim over the native. Trying to get you to write code is like pulling teeth. > [snip useless talk] > >>> Who is here ignoring the known consequences? >> You. Crockford. Probably others. > > Excuse me? > > [snip useless talk] > You've shown 0 good examples of your ideology put to practice (no code). I've shown problems with programs that modifying objects they don't own. Your arrogance isn't justified any more than that of "The world's foremost authority on javascript" (that is what he calls himself, you know). >> Why do yo want to replace built-in function with your own? > > I can't believe this (that's already not even funny ;), so no points > for you). It's already trolling but not demagogy. Again (please pay > maximum attention now and include your brain) - first (a), then (b), > but not the vice versa, ok? Good. > I am not trolling but trying to explain things to an arrogant man who just wants to name-call and won't show any code or any good examples of API design, yet continues to lecture ideology. > [snip useless talk] > I'll tell you what is useless: Your ideology. Good for nothing. >> This is seeming like a more and more of a waste of time. > > Yes, by the truth I've already mentioned that and wanted to conclude > this talk. > >> You've got 0 rational argument > > Ok, take a cookie (or cracker), you have deserved it. And yeah, learn > ECMAScript and its ideology Your idealistic philosophies and ideology, coupled with your arrogance are getting in the way of rational decision making. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 8 Jan 2010 18:30
Garrett Smith wrote: > Dmitry A. Soshnikov wrote: >> On Jan 8, 1:34 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> >> [snip useless (talk === demagogy)] >> Please don't snip headers. Well I guess that is too much to expect from one who writes fake code using Microsoft Word and publishes that on the NG as arguments via Google Groups. [snip] > Results in Firefox 3.5: > > dcTrim: 7027 > trim: 2307 > > The native the user-defined "dcTrim" performed three times slower. Since > you won't normally trim that many strings, you won't be saving 5 > seconds. That is why I fairly called it a "minor performance penalty". Correction: not "native user-defined", just "user-defined". -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |