Augmenting Types
in [JavaScript]
|
From: Eric Bednarz on 4 Jan 2010 03:36 David Mark <dmark.cinsoft(a)gmail.com> writes: > On Jan 3, 1:50 pm, Jorge <jo...(a)jorgechamorro.com> wrote: >> authors know about .hasOwnProperty() existence and purpose ? > > You truly are a student of Crockford. For about the millionth time, > that method doesn't work in "ancient" browsers like Safari 2. It works in Safari 2.04; I would expect that people who are stuck with OS X 10.4 would still run system updates. > I see > it used without proper feature detection Booo! :-)
From: Thomas 'PointedEars' Lahn on 4 Jan 2010 05:51 David Mark wrote: > And I think it bears pointing out that there is no recovery from > [an "automation server can't create object ..."] exception. Wrong, try-catch can handle this. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Jorge on 4 Jan 2010 05:52 On Jan 4, 2:06 am, JR <groups_j...(a)yahoo.com.br> wrote: > On Jan 3, 10:33 pm, Jorge <jo...(a)jorgechamorro.com> wrote: > > > On Jan 4, 1:18 am, JR <groups_j...(a)yahoo.com.br> wrote: > > > > No, it isn't, even in case you know exactly what you're doing. > > > Dear God ! Another step towards the abyss ? > > The guy asked our opinion. Mine was stated: I'm against type > augmentation although I know it's possible and can increase > expressiveness of JS. That's just an opinion and I can't see how being > prudent would be a step towards the abyss? I believe in "If it isn't > broken, don't fix it.", and "If something can go wrong, it will." That user defined properties -inherited or not- are enumerable isn't something to be afraid of, and String.prototype.trim() is a good example of handiness that can't break anything. If it broke a certain script, the culprit would be that script's author's ignorance, but instead you and Mark are mistakenly pointing at a nice feature of the language as the culprit and advocating to mutilate it... ¿? -- Jorge.
From: Thomas 'PointedEars' Lahn on 4 Jan 2010 06:18 Jorge wrote: > JR wrote: >> Jorge wrote: >> > JR wrote: >> >> No, it isn't, even in case you know exactly what you're doing. >> > >> > Dear God ! Another step towards the abyss ? >> >> The guy asked our opinion. Mine was stated: I'm against type >> augmentation although I know it's possible and can increase >> expressiveness of JS. That's just an opinion and I can't see >> how being prudent would be a step towards the abyss? Because your opinion expressed above is not based on prudence but on irrational fear instead. It goes without saying that if one knows exactly what they are doing, they must also be aware of the side-effects. >> I believe in "If it isn't broken, don't fix it.", In a way, a trim() prototype method present in one implementation and not in another is something that is borken in the latter because it would require a different approach in the main code. On a second thought, one might also want to program non-interoperabilities out of the trim() implementation which is a goal worth pursuing despite the reduced efficiency of the user-defined code. >> and "If something can go wrong, it will." Fear is a bad advisor. > That user defined properties -inherited or not- are enumerable isn't > something to be afraid of, But to be kept in mind. > and String.prototype.trim() is a good example of handiness that can't > break anything. That is, if it is done properly, contrary to the example. For it is rather unlikely that anyone would plainly for-in iterate over String instances or values without general property detection or side-effects in mind. > If it broke a certain script, the culprit would be that script's > author's ignorance, but instead you and Mark are mistakenly pointing > at a nice feature of the language as the culprit and advocating to > mutilate it... ¿? ACK PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: JR on 4 Jan 2010 09:01
On 4 jan, 09:18, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Jorge wrote: > > JR wrote: > >> Jorge wrote: > >> > JR wrote: > >> >> No, it isn't, even in case you know exactly what you're doing. > > >> > Dear God ! Another step towards the abyss ? > > >> The guy asked our opinion. Mine was stated: I'm against type > >> augmentation although I know it's possible and can increase > >> expressiveness of JS. That's just an opinion and I can't see > >> how being prudent would be a step towards the abyss? > > Because your opinion expressed above is not based on prudence but on > irrational fear instead. It goes without saying that if one knows exactly > what they are doing, they must also be aware of the side-effects. No, it's prudence against the many that *think* they know what they're doing. > >> I believe in "If it isn't broken, don't fix it.", > > In a way, a trim() prototype method present in one implementation and not > in another is something that is borken in the latter because it would > require a different approach in the main code. Why this insistence on the term 'borken'? Why not writing broken? > On a second thought, one might also want to program non-interoperabilities > out of the trim() implementation which is a goal worth pursuing despite the > reduced efficiency of the user-defined code. > > >> and "If something can go wrong, it will." > > Fear is a bad advisor. The cemetery is full of fearless men. > > That user defined properties -inherited or not- are enumerable isn't > > something to be afraid of, > > But to be kept in mind. > > > and String.prototype.trim() is a good example of handiness that can't > > break anything. > > That is, if it is done properly, contrary to the example. For it is rather > unlikely that anyone would plainly for-in iterate over String instances or > values without general property detection or side-effects in mind. > > > If it broke a certain script, the culprit would be that script's > > author's ignorance, but instead you and Mark are mistakenly pointing > > at a nice feature of the language as the culprit and advocating to > > mutilate it... ¿? > > ACK No, you are mistaken. Read again: I did not advise anyone to 'mutilate' JS, instead I commented (as an opinion, of course) to not use the 'augmenting-types' capability, given the context mentioned earlier in the same post [Douglas Crockford's note about the need of being careful when there are other scripts in the page]. "Not to use something" is totally different from "mutilating something". -- JR |