[Python-checkins] CVS: python/dist/src/Lib string.py,1.46,1.47

[Gordon McMillan]

bjorn wrote:

> I must respectfully disagree.  When doing OO design, the fundamental question
> is "if I want to do 'foo', to what am I doing 'foo'?"...  In this case "if I
> want to 'join', what am I 'joining'?", the answer is that you're joining a
> sequence type.  Thus, IMHO it the natural (and extensible to user types) way
> to do it would be:
> 
>     [1,2,3].join()
>     (1,2,3).join(' ')

string.join only works on lists of strings. If you introduce a 
special "sequence of strings" type, then join could be a 
method on that. Otherwise, you need to work out some new 
semantics.
 
> if you think of another domain, say a gui with a textarea this might become
> clearer. Nobody would want to write:
> 
>     "foo bar".put(textarea)

If textareas had a well defined interface that strings knew 
about, that would be fine, but since the interface would be:

> since the "right" way to do it would be:
> 
>     textarea.put("foo bar")

...it would be kind of silly (like a lot of C++ / Java <wink>).

> Besides has anyone even considered " ".join(myUserListDerivedClass)? How about
> " ".join(myTreeThatHasLinear__getitem__)?

But the scope here is the existing "string.join". The fact that 
the procedural interface has the instance as the 2nd arg is a 
distraction. It is a string method, not a list method.

- Gordon