Path: csiph.com!usenet.pasdenom.info!dedibox.gegeweb.org!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <4354949.izIPKcei6W@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Sun, 01 Sep 2013 15:06:41 +0200 User-Agent: KNode/4.10.5 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+&. <1780396.7rZ4NEZdN2@PointedEars.de> <45644598-181c-47d4-8ba4-d768f4633a4b@googlegroups.com> MIME-Version: 1.0 Lines: 207 NNTP-Posting-Date: 01 Sep 2013 15:06:44 CEST NNTP-Posting-Host: b7f5d4c0.newsspool3.arcor-online.net X-Trace: DXC=fgmm3:jZan6^cW`WBF>WQ […] Thomas 'PointedEars' Lahn wrote: >> brettz9@gmail.com wrote: > > ',' + ['a', 'b', 'c'].join(function (item) { // Maybe "prev" could be an > (optional) second argument > return ',' + item.toUpperCase(); > }); // ,A,B,C > > ...as opposed to the DRY-violating: > > ['a', 'b', 'c'].reduce(function (prev, item) { > return prev + ',' + item.toUpperCase(); > }, ''); // ,A,B,C ["", "a", "b", "c"].map(function (item) { return item.toUpperCase(); }).join(",") or simply String(["", "a", "b", "c"]).toUpperCase() are equivalent. And again I do not see the use-case. (JFYI: It is customary to use double-quotes as string delimiter unless apostrophes are required or better readable. They stand out more.) > My recurring use cases have tended to be within template code where I want > to build a string inline in as terse and implementation-detail-free a > manner as possible. In that case I suggest to use a template implementation instead. I am working on one myself, based on Python’s. >> > Similarly, with split, one may not require the first and last elements >> > of the resulting array, so a corresponding ability to easily strip the >> > first and last elements in the resulting array could also be added. >> > >> > '|a|b|c|'.split('|', undefined, true).join(',') // a,b,c >> >> Please explain the meaning of the second and third argument passed to >> your proposed modification of the standard String.prototype.split() >> method. > > The second argument is the standard second argument, "limit". The third > argument is the counter-part to the proposed join() boolean: optionally > drop the outer matches (in this case, "|" at the very beginning and very > end). Probably since I never had a need for it, I was not *consciously* aware of the second parameter of String.prototype.split(), which has been introduced with ECMAScript Edition 3 (I would assume few people are). However fortunately, the ECMAScript Support Matrix already has the corresponding test case, and according to the results that feature can be considered safe. >> The same result can be achieved with >> >> "|a|b|c|".slice(1, -1).split("|") >> >> or >> >> "|a|b|c|".split("|").slice(1, -1) > > I don't like those options for two reasons: > > 1. I really believe in helping developers avoid implementation details. It > is arguably less error prone, it is easier for beginners to grasp, and it > makes code easier for veteran programmers to quickly digest as well. Of > course, it is not practical to standardize with declarative expressions > for every possible need out there, but at least for common cases, it would > be helpful. I do not agree with your assessment at all. New, mostly untested, code is more error-prone than old, proved code. To-be-JIT-compiled user code is less efficient than vendors’ precompiled machine code. Beginners should learn the basics, not merely learn how to use a particular library, and they should not have to work around its quirks. Veteran developers are accustomed to quickly writing code the standard way, and will be even slower to accept other ways than beginners. That said, I do have written libraries myself (JSX in particular), but I have written them mostly on an as-needed basis to simplify decision branches, or streamline development across implementation released in different times; and as a tool for teaching. Not merely for syntactic sugar. > 2. If it were a regular expression returning values of potentially > differing lengths, your approach would not work. The first variant would not; the second one would, because String.prototype.split() can take a regular expression as argument: /* ["a", "b", "c"] "||||a|||b||c|".split(/\|+/).slice(1, -1) (since ES 3; now in ES 5.1, §15.5.4.14) > Ok, thank you for this and your other recommendations/references. You are welcome. Also, keep your Subject header field value short as it will likely be trimmed for display. This applies to all electronic discussion media. Note my change of Subject here (the “(was:” part is to be removed on replies). >> Also, be aware that the way you are doing it now, the new or changed >> properties are enumerable (show up in for-in iteration), and you cannot >> prevent this from happening in implementations of ES Editions earlier >> than 5 (see Object.defineProperty()). > > Did you mean to include this or was this just a part of boilerplate? I mean you should use Object.defineProperty() if available, unless you want those properties to be enumerable. (Now that ES 5.x is reasonably stable, it is on my to-do list as well. One problem to solve is that JScript is FUBAR in that regard; you can augment host objects, but not native objects, this way.) > In my code here, I have only redefined existing methods. That does not matter. Not all implementations will keep the internal [[DontEnum]] or [[Enumerable]] attribute value when you assign a new value to a built-in property. >> - avoid posting to Usenet using the borken, spammed Google Groups. Use a >> locally installed newsreader application instead, like KNode, >> SeaMonkey, or Thunderbird. > > Is this a strict requirement due to some bad output generated by Google > Groups or merely general advice to the user? It is a strong recommendation due to a lot of inappropriate output generated by Google Groups (particularly: often full quotes because quotations are collapsed only in the Web interface, and the user is not [made] aware of that; lines of astronomical lengths due to lack of automatic line break, and quotations with interleaved empty lines), and due to it being the source of a lot, if not most, of the spam (because the spam filters at Google Groups only *hide* the spam *at Google Groups*, they never delete the spam, and apparently they could not care less about complaints about spammers). I for one will think twice before I reply to a posting injected via Google Groups. In fact, usually I filter out all those postings, so I do not read them in the first place. > I don't want to be forced to download a bunch of messages of no interest > to me, A newsreader will only download the messages that you select, in the newsgroups you subscribed to. At first it will only download the header of the messages of the newsgroups you have subscribed to (but this is customizable depending on the application). > adding unnecessarily to web traffic for everyone, Again, this is _Usenet_; it is neither the Web, nor necessarily the Internet. You are using a (buggy) interface to Usenet, on the Web which in turn runs on top of the Internet infrastructure. > nor do I wish to wait until I get replies to disable my subscription A newsgroup subscription in Usenet is not like a mailing list subscription. It is merely a choice you make which newsgroups are listed at computer. (Google Grooups has muddled the difference there as well.) > (and repeat these steps every time I may come around again to make a new > post), A newsreader will keep a newsgroup in the list of newsgroups you have subscribed to until you unsubscribe from it. RTFM. > etc. Your FAQ also links to Google Groups, btw. It is not exactly *my* FAQ (although I have made a few adjustments to the original due to the latter being unmaintained), and it has linked and is linking to Google Groups as a newsgroup *archive*. [I can only hope that you cannot find any endorsement of using Google Groups there (given the previous maintainer's predilection for Google Groups, that is a distinct possibility).] >> - always post the minimum of the relevant code *here*. While a Web >> reference is useful, this is _not_ the Web, and you cannot assume >> people going to your Web site, looking up your code there. > > In this case, there was no need to follow the link, Yes, there was. > […] with the main thrust being about the proposed API rather than an > implementation. The API leads to the implementation. What good is a good API if the implementation it leads to is FUBAR? > I presume we don't need to post any library we may reference unless the > code is under discussion. Because one wants to avoid people having to switch media, posting the relevant code is prudent, unless its size exceeds certain limits. -- PointedEars Twitter: @PointedEars2 Please do not Cc: me. / Bitte keine Kopien per E-Mail.