[Python-checkins] CVS: python/dist/src/Lib string.py,1.46,1.47
Gordon McMillan
gmcm at hypernet.com
Tue Feb 22 14:00:19 EST 2000
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
More information about the Python-list
mailing list