OK,

Dave

At 14:18 -0700 5/30/00, Dan Ingalls wrote:

"David N. Smith (IBM)" dnsmith@watson.ibm.com wrote...

...

Here are some extensions to SequenceableCollection that I use all the time. There are a couple of similar methods, allButFirst and allButLast, but these are unforgiving in that they burp when asked for a character and it isn't there.

These are all forgiving; asking for the last 5 characters of a 3 character string answers the last three characters. I've found this much more useable in practice, allowing me to virtually never have to write #copyFrom:to: which is all to easy to get wrong (off by one errors).

Class SequenceableCollection: butFirst Answer all but the first character butFirst: n Answer all but the first n characters butLast Answer all but the last character butLast: n Answer all but the last n characters first: n Answer the first n characters last: n Answer the last n characters

I agree with the convenience of extending the current first/allButFirst pattern to N items -- there are a number of places in the system already where this would help.

I'm skeptical about the value of forgiveness in such code. For one thing, it often delays the appearance of bugs to where they are more confusing. For another, it often turns out that tests are needed elsewhere anyway, when results come from "forgiving" code -- ie, you don't really know how many items you actually got, whereas you do with strict code.

I'm opposed to having BOTH an allButFirst family AND a butFirst family of methods in the release (but of course it's a fine distinction for maintaining this package as a goodie).

My counter-proposal for the release itself would be to extend the current family to N items, using "allBut" naming and strict code.

• Dan

PS: Note that once you have the N-item versions, it's quite easy to write forgiving code where you really want it, as in

str first: (3 min: str size).

_______________________________ David N. Smith IBM T J Watson Research Center Hawthorne, NY _______________________________ Any opinions or recommendations herein are those of the author and not of his employer.