to learn jQuery if already using prototype
in [JavaScript]
|
From: AKS on 19 Apr 2008 04:14 On Apr 19, 2:02 pm, AKS <aksus...(a)yandex.ru> wrote: > "Special" object? No, it's not: Excuse me, I was mistaken!
From: Lasse Reichstein Nielsen on 19 Apr 2008 04:54 "J.S.Criptoff" <J.S.Criptoff(a)googlemail.com> writes: > No, Lasse, it is "special" object in scope chain created to keep > FunctionExpression name only (ES 13), no bug here. Indeed, by bad. It only occurs when the inner function expression is a named function. It's not the activation object, and it is as specified in the standard (which probably means that the standard should be changed, becuause that's a bad choice!) /L -- Lasse Reichstein Nielsen - lrn(a)hotpop.com DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html> 'Faith without judgement merely degrades the spirit divine.'
From: Richard Cornford on 19 Apr 2008 07:01 Lasse Reichstein Nielsen wrote: > J.S.Criptoff writes: > >> No, Lasse, it is "special" object in scope chain created >> to keep FunctionExpression name only (ES 13), no bug here. > > Indeed, by bad. It only occurs when the inner function expression > is a named function. It's not the activation object, and it is > as specified in the standard (which probably means that the > standard should be changed, becuause that's a bad choice!) That does seem a bit of an oversight on the part of the authors of the specification (possibly not seeing the full consequences of what they were writing). On the other hand the infamous JScript(tm) bug where using an Identifier with a function expression results in the creation of an additional function object as a named property of the current Variable object (and during variable insanitation) already means that using Identifiers with function expression has inconsistent consequences. So doing so was already a bad idea. Richard.
From: Richard Cornford on 19 Apr 2008 07:40 J.S.Criptoff wrote: > While c.l.j regulars are ridiculing John Resig's first > javascript book he's writing the second one - "Secrets > of the JavaScript Ninja". <snip> That would not necessarily have to such a bad thing as it may at first appear to be. The first book was published in 2006 and it is possible to learn a great deal in two years. Granted I don't think that John Resig's attitude will lend itself to facilitating his learning anything effectively. Richard.
From: Richard Cornford on 19 Apr 2008 12:02
Andrew Dupont wrote: > On Apr 17, 10:57 am, Thomas 'PointedEars' Lahn wrote: >> So what? They all have made the wrong design decision. Whether >> source code is good is not defined by those who use it but by >> the source code itself. > > And the source code makes its divine message known through you, > its emissary in the human realm? (And I thought I had to read > the _comments_ to understand how code worked. What a fool I > was.) It is very often a characteristic of 'good' source code (at least in higher level languages) that the code can easily be understood by reading the source code. However, the last significant discussion of the Prototype.js source code that we had here (the link, via Google groups, to that discussion is in one of the posts in this thread) showed that the authors of Protoype.js obviously did not understand the code they were writing (instead finding themselves victims of code that exhibited behaviour that conformed with their expectations by no more than coincidence (but then only on the browsers were they had observed that behaviour)). Under those circumstances the code itself if more informative than the comments because an author who does not understand the code they are writing cannot comment it in an informative way. > You're that guy who stubbornly insists that music is not a > matter of taste - who cannot suffer the fools who dare to > question the status of Rush's _Fly By Night_ as the best > album of all time in any genre. These philistines! They ply > their ears with the bleating of musical sheep! > >> Yours is an "appeal to authority" fallacy, BTW. I didn't think that was an appeal to authority, more of an appeal to bulk, in some sens. > You call foul for a logical fallacy against someone who was > rebutting your claim that two immensely popular JavaScript > libraries are "junk"? That wasn't a rebuttal, more of an excuse for using the code regardless of any informed assessment of its quality. > I count two right there: "appeal to ridicule" and "misplaced > burden of proof." You're the one asserting they're junk. The > burden of proof is yours. <snip> Where the 'proof' is already a matter of public record, and familiar to anyone who has any more than superficial record of participating in this group, there is no longer any burden of proof at all. Still, if you want examples they are just a short download away. Downloding the latest version of Prototype.js (1.6.0.2) I wondered how long it would take me to find an example of something being done sufficiently badly for that to be easily and unambiguously demonstrated. The answer was under three seconds. During the first scroll through the code, not even looking at most of the details, I noticed this:- | if (Prototype.Browser.WebKit || Prototype.Browser.IE) | Object.extend(String.prototype, { | escapeHTML: function() { | return this.replace(/&/g,'&') | .replace(/</g,'<') | .replace(/>/g,'>'); | }, | unescapeHTML: function() { | return this.replace(/&/g,'&') | .replace(/</g,'<') | .replace(/>/g,'>'); | } | }); - which is adding a couple of escaping/unescaping methods to the - String.prototype - object based upon a condition. Seeing it I asked myself whether the author had made the rookie mistake that every web development novice always makes (and the thing I deliberately double check every time I ask someone to write an escaping/unescaping function for any purpose), and the answer was a very obvious "yes they have". One of the arguments paraded in favour of these libraries is that they are examined, worked on and used by very large numbers of people, and so they should be of reasonably high quality because with many eyes looking at the code obvious mistakes should not go unnoticed. My experience of looking at code from the various 'popular' libraries suggests that this is a fallacy, because (with the exception of YUI (for obvious reasons)) all of the 'popular' library contain numerous obviously stupid mistakes. The problem probably being that it does not matter how many people may look at, review or use, any particular piece of code, if none of them understand what they are doing none of them are capable of spotting the obvious mistakes. In this case we have a very obviously stupid use of user agent string based browser detection to make a decision that would be more logically made with feature detection. That is, the attempt is to add two methods to the - String.prototype - in environments were those methods do not already exist. Obvioulsy the is a one-to-one relationship between - String.prototype.escapeHTML - having trueness and an environment where a - String.prototype.escapeHTML - has been implemented. While the relationship between a user agent sting an a - String.prototype.escapeHTML - method is at best tenuous, and certainly not guaranteed to be comprehensive or continuous over time. But that is not the rookie mistake I alluded to above. That mistake is that the escaping and unescaping methods are not symmetrical. That is, if you apply the second to the output of the first you will not always end up with the character sequence you start with. I.E.:- <script type="text/javascript"> alert('<'.escapeHTML().unescapeHTML()); //alerts "<" alert('&lt;'.unescapeHTML().escapeHTML()) //alerts "<" <script> - and that is pretty bad by anyone's standards (except maybe VK's). Richard. |