Stephen Smith wrote:
05. Re-naming classes and methods. I think that names should be
re-evaluated to make sure that they still make sense in the new
code. For example, with the singletons we have
TruePredicate.getInstance(), but this becomes relatively silly when
we have static imports. There's only one getInstance() method that
we can import per class. Therefore it should be
TruePredicate.getTruePredicate(), which will be simplified to the
shorter getTruePredicate() in the code.
That's an interesting idea, Stephen - I haven't considered the impact
of JSE5 static imports on the Singleton design pattern before.
However, I'd reserve a +1 on it solely because I'm a little worried as
to how far we're going to open this "reboot" can of worms.
I say go the whole way - however, in voting for 01. (deprecated
methods), I would also be inclined to deprecate the old-standard way of
doing things.
If we go the way of a renamed package, we can always have a
compatibility jar that will map the old to the new stuff. However, I
really like the namespace - I'd propose that we keep the package name
the same, and add a org.apache.commons.collections-compat package for
transitional utilisation. That's pretty easy to do with a find replace
in source (we've broken binary compatibility anyhow).
Otherwise we could make it a two-stage/option release. There will be a
compatibility migration release (throughout development), which sets the
new direction, but retains old (and now-deprecated) methods, and then
once that's stable, we can remove all the old-standard methods
completely from the trunk and release that as well - both would be
maintained in parrallel. Even better would be to have an automated
build that is able to do this. The compatibility build would only be
for the first version.
Both options have their ugliness and pain, but I think it's short term
pain for long term gain. How much of a better gift can we give future
developers than a beautiful, well crafted api? In my projects, order of
import is (log4j, collections, easymock, joda-time). Collections is a
biggie, and probably gets used (or at least should be) in well over half
of all projects.
For example. if we're really going to push the boat out on this, what
about hiding public constructors in static utility classes? It's the
sort of thing CheckStyle whines about, and normally with good reason.
I've never understood why CollectionUtils#CollectionUtils is public,
even with a comment along the lines of "should not normally be used".
If every method is static (and the class is therefore potentially
finalised), when would it ever be used?
Hah - snap! I was just about to come back and talk about checkstyle in
another thread - is there an apache checkstyle convention that we are
able to use for this to ensure the code is properly formatted? I
support the above, but would also prefer to go a bit further (e.g. if
statements [that represent exceptional conditions] with return
statements should not be followed with an else, as the "else" should
really be the normal flow of the method).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
