Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!newsfeed.straub-nv.de!noris.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <8862364.SEqChMirdb@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Mon, 18 Jul 2011 18:17:14 +0200 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 8Bit Subject: Re: Nasty language semantics Newsgroups: comp.lang.php References: <4e2050e3$0$48996$dbd4f001@news.wanadoo.nl> <76idnXX5CP7_3r7TnZ2dnUVZ_rGdnZ2d@posted.localnet> Followup-To: comp.lang.php MIME-Version: 1.0 Lines: 47 NNTP-Posting-Date: 18 Jul 2011 18:17:14 CEST NNTP-Posting-Host: b96df23a.newsspool2.arcor-online.net X-Trace: DXC=nAK];h6]L]SAX0F2i> The Natural Philosopher wrote: >> I want to know that '1.02' + '3.7' is reliably going to be either '4.72' >> or '1.023.7', not implementation dependent, as I found in at least one >> Javascript example. To the best of my knowledge there is no such non-conforming ECMAScript implementation. You (or the author of the example) must have been doing something else wrong. > Javascript's main problem here is using a common numerical operator (+) > as a string operator as will AND allowing numbers to promoted (or > demoted) to strings. Javascript *could* have picked a different > operator for string concatenation, something less likely to cause > ambigious interpretation. There is no "Javascript"¹. If you think about this, it would have been rather difficult for the designer of JavaScript (and, as a consequence, the ECMAScript committee) to choose another operator for concatenation that was widely accepted, given that he needed the language to resemble Java (hence the name, changed from LiveScript). They could not use today's PHP's `.', because that was already taken for property access by Java (where PHP has the C++-ish `->' instead). They could not use `<<' etc, because that was used for SHL/SHR already. And they could not have skipped the implicit type conversion because the language needed to be loosely typed (one design goal was a language that was flexible, and easy to use, compared to Java). I wouldn't mind if they chose C++/Python's optional whitespace operator for concatenating string literals (that would have made writing/reading long strings in source code considerably easier), and PHP's variable expansion mechanism or Python's sprintf() mechanism (`%') for dealing with "concatenation" of non-string values (IIRC, efforts for built-in string templates in JavaScript 2.0 are underway). (`%' would have been ambiguous, though, and might have meant a unwanted diversion from Java by introduction of a `mod' operator instead.) PointedEars ___________ ¹ -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, (2004)