[Packages] Split-Join in development universe etc

Jason Johnson jason.johnson.081 at gmail.com
Thu Aug 9 20:33:16 UTC 2007


On 8/9/07, Andreas Raab <andreas.raab at gmx.de> wrote:
> It's really just strings. You're getting confused by the (sorry to say
> that) poorly written code.

Well, to be honest I had not looked at the code until you said this.
I based my comments on the discussion we had some time back about how
this should work.  That's why I asked Keith at the beginning if this
was the same package I thought it was.

>It uses <SequenceableCollection> joinUsing:
> <delimiter> which looks very general at first glance but once you dig
> into it you'll notice that it really ought to be <delimiter> join:
> <Collection> and that really only String is a meaningful delimiter here.
> The implementation as it is creates a lot of clutter by doing it the
> other way around and then (needlessly) double-dispatching into Character
> and String. Besides which the code is very poorly formatted and not
> documented at all(there isn't even a single comment anywhere despite
> some highly unusual patterns). Not the kind of stuff I like to see in
> the kernel.

Well, I must admit I was frustrated that I can't see the changes from
Monticello, I have to actually load it, and then open a change set
viewer to figure out what happened.

But the first method I looked at did in fact have a comment. :)  I'm
also a bit confused about the format.  If you don't like the
formatting can't you have it on "pretty print" and always get the same
formatting always?

What we originally discussed about how to do this was that the join
methods would use double dispatch so that they could potentially join
any "delimiter" with any collection.  I'm not surprised that only
Char, String and Array have been implemented so far (note:  one of the
tests has an example of joining one array with another array).

But other then these nit-picks I'll take your word for it.  I just did
a quick scan over the change set to see if what I expected was there,
I didn't try to judge the code quality.

> Concise can mean different things.

To me it means saying something clearly but with no so many words.  In
other words:  Haskell is very concise.  Perl is terse, not concise.

>If it means a bloated collection
> interface to accommodate every single person's pet extensions then I
> think that stinks.

I agree with you.  I'm a bit of a minimalist myself.

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

Well that is certainly unfortunate.  The code could certainly use a
clean up.  But some things are handy.  Like for example, one can
already tell if a collection is empty with "size == 0", but it's still
handy to use #isEmpty, no?  :)

>Split for example, is for all practical
> purposes completely subsumed by findTokens: so why do we need split in
> addition to findTokens?



More information about the Squeak-dev mailing list