Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <1466051.Cd1scNln3u@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Fri, 02 Nov 2012 22:10:43 +0100 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 8Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <1805042.BzeuYpbCYS@PointedEars.de> <7MidnYXvqeq8ggnNnZ2dnUVZ_uGdnZ2d@earthlink.com> Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 128 NNTP-Posting-Date: 02 Nov 2012 22:10:45 CET NNTP-Posting-Host: 18c31a55.newsspool2.arcor-online.net X-Trace: DXC=WPIJXlCC9hCC4i^e1BZ=_HA9EHlD;3YcB4Fo<]lROoRA8kFd\^5HDZm8W4\YJNLJ`:FmdeL>K@YMeRZD8g?;FRTM2cC:RLSD X-Complaints-To: usenet-abuse@arcor.de Xref: csiph.com comp.lang.javascript:17023 Patricia Shanahan wrote: > On 11/2/2012 10:41 AM, Thomas 'PointedEars' Lahn wrote: >> Patricia Shanahan wrote: >>> On 11/2/2012 2:22 AM, Evertjan. wrote: >>> ... >>>> if ( /foo/.test(someString) ) {..} >>>> >>>> I trust not understanding Regex is not a valid counterargument. >>> >>> If I'm prepared to look at it long enough, I can generally work out what >>> a Regex does, but Regex does not seem to me to be a very human-friendly, >>> smoothly readable language. >> >> That depends on the flavor and your experience with them. > > Well, I don't quite have 30 years of experience with regular expressions > yet, but it's getting close. Which flavors? >>> For this particular case, it looks OK if the probe really is a literal >>> such as "foo". >> >> In exactly that case using a Regular Expression is overkill. You need to >> consider that for every RegExp literal in the code (and per ES 5.x in >> every use of that literal), a new RegExp instance is being created. >> >>> Could you show me the code you would use for this if the probe were an >>> actual parameter or variable with unknown contents? >>> >>> That is, what would you use to replace: >>> >>> if(someString.indexOf(someOtherString)) != -1) >> >> It is possible with >> >> if ((new RegExp(someOtherString)).test(someString)) >> >> but I would not use that. However, the following can be useful and >> necessary: >> >> if ((new RegExp(someOtherString, "i")).test(someString)) >> >> The caveat in both cases is that any special characters in the value of >> `someOtherString' that should not assume their special meaning need to be >> escaped. This can be accomplished with a previous replace() – >> >> if ((new RegExp(someOtherString.replace(/…/g), "i")).test(someString)) >> >> – or with a user-defined method: >> >> if ((new RegExp(jsx.regexp.escape(someOtherString), "i")) >> .test(someString)) > ... > > Do you feel this is an improvement on basing the contains test on the > String indexOf function? The latter variants certainly are. > If so, why? Case-insensitive matching. > Or is this just an illustration of how you would do it with regular > expressions if indexOf did not exist? Yes. > My general view of regular expressions is that they have a few uses, but > I've often seen code, in many languages, that seems to use them for the > sake of using them, at the expense of making the code less readable. The longer and better I know them, the more valid reasons I find to use them; not only *in* source code, but also *for writing* source code. AISB, the readability of (code using) regular expressions depends very much on the flavor of regular expressions that is used (that the language/IDE is capable of) and the way you (can) write them in a programming language/IDE. Because RegExp *literals* need to be delimited with `/' in ECMAScript implementations, some people think they need to escape `/' in string literals passed to the RegExp constructor (or elsewhere), or all special characters in character classes; actually they do not. Attempting to simplify a regular expression often goes a long way towards better understanding them, and vice-versa. You can find a lot of examples of that in my follow-ups in comp.lang.ALL and de.comp.lang.ALL. In that sense I have devised RegExp.prototype.concat() (or jsx.regexp.concat()) so that a regular expression definition can span more than one line, and can have variable parts, *without* the need to use a string literal throughout (and the extra escaping that is required then) – or to wait for TC39 and implementors to catch up; var s = "baz"; var rx = /foo/ .concat(/bar/i) .concat(s) .concat(/bla/gm); being equivalent to var rx = /foobarbazbla/gim; And I had devised (independently of similar approaches) jsx.regexp.RegExp() so that you can use at least some features of Perl and Perl-Compatible Regular Expressions in ECMAScript implementations, many of which make regular expressions more powerful, some of which make them better readable and understandable. For example, var rx = jsx.regexp.RegExp( /\s+ \w+ \s+ # Word delimited by whitespace/, "x"); is equivalent to var rx = /\s+\w+\s+/; (Existing approaches are informing the implementation of new features now.) See also: PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, (2004)