commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: chop/chomp/slice - how to deprecate?
Date Mon, 17 Mar 2003 22:01:48 GMT


On Mon, 17 Mar 2003, Alex Chaffee / Purple Technology wrote:

> I've made a first pass at reworking chop and chomp, so that:
>
> * chop works like perl (always remove last character)

This shouldn't change right? Same as before?

> * chomp works like perl (remove last character only if it's a newline)

+1. Big commenting etc, whenever we do a release, we need to make sure
this gets highlighted as a change. I'm planning to run JavaDiff over the
1.0.1/2.0 release but will have to have an additional post.

>
> * chopNewline is deprecated with a message "use chomp instead"

+1

>
> * all the previously named "chomp" functions are renamed "slice":
> 	slice, slicelast, getslice, preslice, getpreslice

Were we against 'get' for a static method? Not that I'm bothered, provided
we use camel-case. getSlice etc.

The get's should not return the separator, as I've never really found this
useful. People can just deal with the lack of symmetry :)

> Henri, is this an acceptable name change?

+1 from me. There's a shortage of words in the world anyway, so while I'm
sure someone might consider slice to be taken.

[for example, in LPC I can do:    "foo, bar lala"[0..<5]  which is often
called slicing [in LPC, strings may be treated as arrays]]


> Before I check it in, I'd like some consensus on the deprecation
> strategy.  We've renamed some methods, and also changed the behavior
> of an existing method -- slighly, but significantly.
>
> Do we...
>
> * Check it all in as is, and just make sure to document the changes in
> the readme for the next release?

This'd get my vote. But I believe in breaking things.

> * Put in stub implementations for the old chomp* functions and mark
> them with a @deprecated tag?

Probably the consensus which will be reached.

> * Contact anyone who's using them -- I'm thinking about Gump, and its
> concept of dependencies between Jakarta projects -- If so, how would
> we locate all these users?

They deal. As I may be letting slip, I prefer the idea of a project with
only a few happy users to a project with an enourmous amount of management
which drowns the project.

> If anyone wants to see my changes, let me know and I'll send you a
> patch file.

Nah, I'll be cvs diff'ing before updating :)

Hen


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message