Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.javascript > #21094

Re: Proposal for encapsulator boolean 2nd arg for Array.prototype.join() and innerOnly boolean 3rd option for split()

Message-ID <1780396.7rZ4NEZdN2@PointedEars.de> (permalink)
From Thomas 'PointedEars' Lahn <PointedEars@web.de>
Organization PointedEars Software (PES)
Date 2013-08-29 10:42 +0200
Subject Re: Proposal for encapsulator boolean 2nd arg for Array.prototype.join() and innerOnly boolean 3rd option for split()
Newsgroups comp.lang.javascript
References <563b9f80-1d04-4a54-b581-2e6c2a057833@googlegroups.com>

Show all headers | View raw


brettz9@gmail.com wrote:

> Per https://gist.github.com/brettz9/6373468 (live at
> http://brett-zamir.me/tests/proposal-join-split.html ), I have come across
> a need periodically to do joins and use the same glue surrounding the
> join. I think it would be handy if one could do:
> 
>     ['a', 'b', 'c'].join('|', true); // '|a|b|c|'

The prevalent opinion appears to be that boolean arguments to determine the 
behavior of a function are not a good idea, summarized in “A (highly 
cohesive) function should do one thing and one thing only.” and GNU's “one 
tool for one purpose”.

<http://programmers.stackexchange.com/questions/147977/is-it-wrong-to-use-a-boolean-parameter-to-determine-behavior>

I, too, have my share of making this mistake.  The more you want to modify 
the behavior of a function, the more you come you tend to come to the 
conclusion that a single options argument of the Object type is the better 
approach.  And there comes a point when you want to write a new function for 
the new behavior instead because you cannot keep the order of the arguments 
in mind.  [My experience shows that functions/methods taking more than a 
handful (5) *positional* arguments (where order matters) are hard to use 
because of that, sometimes even more than 3.]

There is no good reason why one could not write

  "|" + ["a", "b", "c"].join("|") + "|"

instead, using the standard Array.prototype.join() method.  Or, if you are 
concerned about DRY,

  var delim = "|";
  delim + ["a", "b", "c"].join(delim) + delim
 
> 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 same result can be achieved with

  "|a|b|c|".slice(1, -1).split("|")

or

  "|a|b|c|".split("|").slice(1, -1)

so again I do not see the advantage of your proposal here.

[.join(",") is optional if the value of this expression is used in string 
context, as split() returns a reference to an Array instance whose inherited 
toString() method does what .join(",") does.]

I am going to respond to your RegExp.prototype.forEach() suggestion later 
this week.

In general, please

- take your suggestions for the next Edition of ECMAScript to the ES Discuss
  mailing list instead; a so-called “strawman” document may be the outcome:

    <http://wiki.ecmascript.org/doku.php?id=strawman:strawman>

  ECMAScript implementations being dynamic languages, we all have extended
  built-in objects one way or the other before for syntactic sugar.  It is
  not necessarily a good thing to make your use-cases the standard for
  everyone.  The people most likely to give you a proper review with regard
  to that are reading that mailing list.  You want to keep some
  recommendations in mind when doing this:

    <http://wiki.ecmascript.org/doku.php?id=harmony:harmony>

  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()).

- post using your real name (you may include your nickname for recognition)

- avoid posting to Usenet using the borken, spammed Google Groups.  Use a
  locally installed newsreader application instead, like KNode, SeaMonkey,
  or Thunderbird.

- 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.

<http://jibbering.com/faq/#posting>
<http://PointedEars.de/faq#posting>

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Proposal for encapsulator boolean 2nd arg for Array.prototype.join() and innerOnly boolean 3rd option for split() brettz9@gmail.com - 2013-08-28 19:09 -0700
  Re: Proposal for encapsulator boolean 2nd arg for Array.prototype.join() and innerOnly boolean 3rd option for split() Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-08-29 10:42 +0200
    Re: Proposal for encapsulator boolean 2nd arg for Array.prototype.join() and innerOnly boolean 3rd option for split() Brett Zamir <brettz9@gmail.com> - 2013-08-31 19:37 -0700
      Proposal for Array.prototype.join() and String.prototype.split() (was: Proposal for encapsulator boolean 2nd arg for Array.prototype.join() and innerOnly boolean 3rd option for split()) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-09-01 15:06 +0200

csiph-web