[Packages] Split-Join in development universe etc

Colin Putney cputney at wiresong.ca
Thu Aug 9 16:20:27 UTC 2007


On Aug 9, 2007, at 12:11 AM, Andreas Raab wrote:

>> Wanting code to be concise is code smell?  If you meant adding a  
>> method to collections that only joins strings is a code smell then  
>> ok, but otherwise.... well I strongly disagree to say the least.
>
> Concise can mean different things. If it means a bloated collection  
> interface to accommodate every single person's pet extensions then  
> I think that stinks. And that's exactly what we've seen over the  
> last years - ever-increasing amounts of partially overlapping  
> functionality none of which is widely used and only makes it more  
> difficult to find the few truly useful methods. Split for example,  
> is for all practical purposes completely subsumed by findTokens: so  
> why do we need split in addition to findTokens?

Agreed.

I was actually thinking of the larger design issue here - the  
circumstances under which #join: would be useful. Let's look at a  
typical example:

You've got an array of names, that you need to join into a comma- 
separated list. If this list is part of some larger string, you're  
building it by writing into a WriteStream, or you should be, so  
#do:separatedBy: will serve you better than #join:. Ah but wait, you  
actually want to display this list on a web page, so you've got the  
canvas APi in Seaside, and there is no stream. In this case the  
idiomatic Smalltalk would be:

	String streamContents:
		[:stream |
		names
			do: [:ea | stream nextPutAll: ea]
			separatedBy:  [stream nextPutAll: ', '].

Pretty verbose. You need #join:, because you're passing this list  
around to a bunch of different objects, and there's not even a single  
class where you can stick this inside a method called #listOfNames.

Well, that's a code smell. You've got some very generic data types  
here - an array of strings. But that data means something, and the  
knowledge of what it means and the code for processing it is spread  
out all over the place. That array of strings is begging to be turned  
into an object that encapsulates the meaning. Once that's done, you  
can stick that verbose code to join names inside a method and forget  
about it. If at some point you want to change it to semicolons  
instead of commas, you've got one place to change, instead of many  
senders of #join:.

That's not the only possible use of #join: of course. But I think a  
design that causes you to process collections of strings a lot -  
enough that you want it to be concise - is a warning sign.


Colin



More information about the Squeak-dev mailing list