Augmenting Types
in [JavaScript]
|
From: Jorge on 4 Jan 2010 10:11 > On Jan 4, 2:16 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > On Jan 3, 8:11 pm, Jorge <jo...(a)jorgechamorro.com> wrote: > > > Safari 2.0.4 does have .hasOwnProperty()... > > That's as maybe. Now check 2.0.3, then 2.02... http://dev.rubyonrails.org/ticket/9700 (Both have it too) -- Jorge.
From: Thomas 'PointedEars' Lahn on 4 Jan 2010 10:50 JR wrote: > Thomas 'PointedEars' Lahn 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. That is a non sequitur. Why support incompetence? >> 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. False analogy. >> > 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. I am not. > 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]. In this very example augmenting the prototype object can do no harm at all except to those who are stupid enough to for-in over String instances or values without considering enumerable properties. Your categorical "do not use" principle is in effect shifting the responsibility entirely from the library user to the library author. Have you not seen enough inefficient jQuery nonsense to see that this is a flawed concept? > "Not to use something" is totally different from "mutilating something". I was not referring to that part or to your statements in particular there. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: Scott Sauyet on 4 Jan 2010 12:03 On Jan 3, 7:18 pm, JR <groups_j...(a)yahoo.com.br> wrote: > I've read the book too, but in my version (2008 in Portuguese) that > function is slightly different, with one very important feature test: My English copy of the book (2008, first edition) lists the OP's version of the code, and then later in the same section lists the one you supply, introduced by "The prototypes of the basic types are public structures, so care must be taken when mixing libraries. One defensive technique is to add a method only if the method is known to be missing." > Function.prototype.method = function (name, func) { > if (!this.prototype[name]) { > this.prototype[name] = func; > } > }; Clearly this is an improvement on the original. I agree with whoever mentioned that this should have a verb, "setMethod", "addMethod", or some such. I don't much like modifying the prototypes of the built-in objects, although I understand that it can be useful and powerful to do so in at least some circumstances. But Crockford's only justification for this is only that "[W]e no longer have to type the name of the prototype property. That bit of ugliness can now be hidden." His original version (as supplied by the OP) seems to have no advantage. I certainly don't see that this: Number.method('integer', function () { return Math[this < 0 : 'ceil' : 'floor'](this); }); is any less ugly than this: Number.prototype.integer = function () { return Math[this < 0 : 'ceil' : 'floor'](this); }; But when you add in the error checking, it is clearly less ugly than this: if (!Number.prototype.integer) { Number.prototype.integer = function () { return Math[this < 0 : 'ceil' : 'floor'](this); }; } So I think a version of this technique would be useful if you do choose to enhance these prototypes. -- Scott
From: JR on 4 Jan 2010 13:47 On 4 jan, 15:03, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > On Jan 3, 7:18 pm, JR <groups_j...(a)yahoo.com.br> wrote: > > > I've read the book too, but in my version (2008 in Portuguese) that > > function is slightly different, with one very important feature test: > > My English copy of the book (2008, first edition) lists the OP's > version of the code, and then later in the same section lists the one > you supply, introduced by "The prototypes of the basic types are > public structures, so care must be taken when mixing libraries. One > defensive technique is to add a method only if the method is known to > be missing." > > > Function.prototype.method = function (name, func) { > > if (!this.prototype[name]) { > > this.prototype[name] = func; > > } > > }; > > Clearly this is an improvement on the original. I agree with whoever > mentioned that this should have a verb, "setMethod", "addMethod", or > some such. > > I don't much like modifying the prototypes of the built-in objects, > although I understand that it can be useful and powerful to do so in > at least some circumstances. But Crockford's only justification for > this is only that "[W]e no longer have to type the name of the > prototype property. That bit of ugliness can now be hidden." His > original version (as supplied by the OP) seems to have no advantage. > I certainly don't see that this: > > Number.method('integer', function () { > return Math[this < 0 : 'ceil' : 'floor'](this); > }); > > is any less ugly than this: > > Number.prototype.integer = function () { > return Math[this < 0 : 'ceil' : 'floor'](this); > }; > > But when you add in the error checking, it is clearly less ugly than > this: > > if (!Number.prototype.integer) { > Number.prototype.integer = function () { > return Math[this < 0 : 'ceil' : 'floor'](this); > }; > } > > So I think a version of this technique would be useful if you do > choose to enhance these prototypes. > > -- Scott Brilliant! ITA. Cheers, JR
From: Garrett Smith on 4 Jan 2010 15:13
Eric Bednarz wrote: > 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. > Ah but 10.4 can get Safari 3 and 4. 10.3 users are a different matter. Now for 10.3, you'd need to support Safari 1. I do know any way to test Safari 1 on 10.4. Apple bundles the Browser with the operating system, but somehow does not suffer the legal troubles that Microsoft has experienced in doing the same. Apple does a lot worse things and gets away with those, too. Apple a good example what is wrong with business in America. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |