From: "Henri Yandell" <bayard@generationjava.com>
> 1) Notifier class. I need a better name for this. Basically it's a helper
> that uses reflection [used to use Notifiable interface, but I decided it
> wasn't worth it, possibly wants to do both] to help a developer create an
> event/listener list.
>
> It handles the notifying and the queueing etc and the developer just has
> to tell it what method or Listener to use [or both if Listener has
> multiple method signatures].
Not sure how this fits in with either the reflection stuff in [lang] or the
new [klass]. In fact it sounds more like a [pattern] thing. Which of course
raises another debate that needs to happen...
> 2) Mutable primitive classes. Pondered this at the hospital today. Do we
> want such things? new MutableInteger(); mi.setValue(42); etc. Same for
> MutableString.
I don't know whether these stand alone as independent classes. These classes
are similar to those that exist in my own Joda project. If we are to go down
this route, I would like to see use define interfaces as well -
ReadableInteger and ReadWriteableInteger.
> 3) Constant. I'm still unsure if this is good or not :) It's been in and
> out and in etc. My reasons for deciding it was shit was cuz I wanted to
> use == when I initially grew to love it and RMI/Java means I have to use
> .equals. But Enum makes that same choice. So is a simple-enum concept
> needed.
I'd need convincing that having two enum techniques in the same project is a
good idea.
> 4) Pair. Is this Collections? Dunno. Anyway, pairs seem to be nice
> sometimes. I only have one because I was porting the lisp examples to Java
> from the lisp book [yep, i'm that sick].
Definitely should be in. It must implement Map.Entry.
> 5) StopWatch. Currently this is in [util], but as its basically a wrapper
> for System.currentLongTimeBlah I thought I'd mention it.
I haven't looked at it, so can't comment.
Stephen
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
|