I come to praise .join, not to bury it...

[Andrew MacIntyre]

On Wed, 7 Mar 2001, Alex Martelli wrote:

> Suppose I'm building a line of a CSV file, a popular
> textual format where fields are separated (aka joined)
> with commas -- the acronym stands for 'comma-separated
> values'.  So, what I want to do is
>     'comma-separate these values'
> and, since 'separate' equates to join, this equates to:
>     'comma-join these values'
> so, I code:
>     comma.join(these_values)
> *WHAT'S BACKWARDS ABOUT IT*?!

Well thats fine from your point of view, but to me you've just argued
against your point of basing programming around natural language
(although I may have misconstrued your argument).

>From my POV, a method is something that logically "sends a message" to its
object.  In this context, having the joiner be the object is backwards,
because it makes more sense to me to think in terms of:
"send message <join members with separator parameter and return string> to
a sequence"
rather than:
"send message <use self as a separator when joining members of a sequence
parameter and return string> to a string".

But then as a long time C & FORTRAN programmer, I have difficulty with
knowing when an object design is a good one...

--
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andrew.macintyre at aba.gov.au    (work) | Snail: PO Box 370
        andymac at bullseye.apana.org.au  (play) |        Belconnen  ACT  2616
        andymac at pcug.org.au           (play2) |        Australia