> > Won't that cause the same problems when used with for-in loops?
>
> Yes, but only on the object itself and for/in shouldn't be used for
> arrays. I don't believe there should be a conflict.
My words for not using for-in. But if the problem can occur on the object
again, I don't really see the win here.
While I can understand that there are libraries using for-in loops on arrays, I
see no reason to not extent the String prototype. It saves you a lot of trouble
and is pretty and clean.
I think adding this:
String.prototype.trim = function() { ... }
Is much cleaner then $.trim(...)
Iterating over Strings doesn't make much sense, so there is no problem with
for-in loops.
While we are at it: jQuery doesn't promote usage of "bad code". Take the
shadowed XMLHttpRequest: If a library uses that for browser checks, it will
give a wrong result. It may not occur as often as for-in loops on arrays, but
basically it's the same problem.
I have implemented some extensions for String here:
http://fuzz.bassistance.de/sandbox/string.js
It consists of trim, camelize, startsWith (supports offset), endsWith and some
isXXX checks like isAlpha, isUpper, isDigit.
--
Jörn Zaefferer
http://bassistance.de
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
_______________________________________________
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
