commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From __matthewHawthorne <mhawtho...@alumni.pitt.edu>
Subject Re: Mutables Was: [lang] TODO for 2.1
Date Wed, 03 Sep 2003 05:22:53 GMT
I disagree with MutableString containing StringUtils methods.  Perhaps
I'm being too theoretical, but I see StringUtils as a class that _acts_
on strings, while MutableString _is_ a String; just a special type of
String.  

StringUtils contains a ton of methods, I don't like the idea of these
carrying over into other classes, unless it's a case involving direct
inheritance.

I think a strict differentiation between types and the corresponding
classes that act on them can help to keep the API small and simple.

Why not just pass the result from MutableString.getString() into the
desired StringUtils methods?

Am I missing something?




On Tue, 2003-09-02 at 21:19, Henri Yandell wrote:
> I'm ambivalent on the primitives vs lang and think it'll depend on the
> size of the primitives code and how the code feels.
> 
> I'm happy to have it kicking in sandbox to start with, though it makes the
> audit trail a bit harder. Mainly I just want to see the code and start
> complaining :)
> 
> One issue with having [primitives]. My interest is [perversely as usual]
> on MutableBoolean because I think it should be simple and MutableString,
> because it's an outspoke of StringUtils.
> 
> I'd want MutableString to automatically contain any StringUtils method
> which is relevant, which suggests a dependency on Lang. Of course, Strings
> are not primitives, so a MutableString might live in Lang instead of
> primitives. Which means that the 'Mutable' interface will need to live
> either in [mutable] or that [lang] or [primitive] would be considered the
> ancestor project.
> 
> Given this, I think my special case scenarios just completely argued for
> this code being in [lang] :)
> 
> Hen
> 
> 
> On Wed, 3 Sep 2003, Stephen Colebourne wrote:
> 
> > How about coding it in [primitives] and then seeing if it is applicable for
> > [lang]. Uses the sandbox for sandbox type investigation...
> >
> > A case can be argued either way. IMHO, I prefer keeping all new primitives
> > stuff together and focussing [lang] more on Objects.
> >
> > Stephen
> >
> > ----- Original Message -----
> > From: "Steven Caswell" <steve@mungoknotwise.com>
> > To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
> > Sent: Wednesday, September 03, 2003 12:02 AM
> > Subject: RE: Mutables Was: [lang] TODO for 2.1
> >
> >
> > > I'm still not comfortable with primitive. You might have missed my last
> > > posting, but in it I express the opinion that a group of wrapper classes
> > > that enhance functionality of wrappers that live in java.lang, would more
> > > naturally fit in o.a.c.lang.
> > >
> > > Otherwise +1 to the rest of the summary.
> > >
> > > Steven Caswell
> > > steve@mungoknotwise.com
> > > a.k.a Mungo Knotwise of Michel Delving
> > > "One ring to rule them all, one ring to find them..."
> > >
> > >
> > > > -----Original Message-----
> > > > From: __matthewHawthorne [mailto:mhawthorne@alumni.pitt.edu]
> > > > Sent: Tuesday, September 02, 2003 4:36 PM
> > > > To: Jakarta Commons Developers List
> > > > Subject: Re: Mutables Was: [lang] TODO for 2.1
> > > >
> > > >
> > > > Are we now in agreement about the features for mutable
> > > > numbers?  If so,
> > > > I can update my submission with what we've discussed, and
> > > > resubmit the
> > > > enhancement to [primitives] instead of [lang].
> > > >
> > > > The primary changes are:
> > > >
> > > > - Addition of Mutable interface
> > > >
> > > > Mutable
> > > >     setValue(Object)
> > > >     Object getValue()
> > > >
> > > > - Addition of primitive setter/helper in each class.  For example:
> > > >
> > > >     MutableByte
> > > >         setValue(byte)
> > > >
> > > >
> > > > Which package are we thinking...
> > > > org.apache.commons.primitives.mutable?
> > > >
> > > > Anything else?
> > > >
> > > >
> > > >
> > > >
> > > > Stephen Colebourne wrote:
> > > >
> > > > >----- Original Message -----
> > > > >From: "__matthewHawthorne" <mhawthorne@alumni.pitt.edu>
> > > > >
> > > > >
> > > > >>>*) Is a .mutable subpackage okay?
> > > > >>>
> > > > >>>
> > > > >>>>I prefer lang.math
> > > > >>>>
> > > > >>>>
> > > > >>>Boolean? Byte? String? None of these belong in lang.math.
> > > > >>>
> > > > >>>
> > > > >I suggest we get the Mutable Numebr classes in and working
> > > > first, then
> > > > >think about Boolean/String.
> > > > >
> > > > >
> > > > >
> > > > >>>*) Should the MXxxx decorate an Xxxx or an xxxx. [ie primitive
or
> > > > >>>
> > > > >>>
> > > > >>>>wrapper?]
> > > > >>>>I prefer primitive, it would prevent having to create
a new Object
> > > > >>>>
> > > > >>>>
> > > > >each
> > > > >
> > > > >
> > > > >>>>time the value changes, which is a part of the reason
that these
> > > > >>>>
> > > > >>>>
> > > > >classes
> > > > >
> > > > >
> > > > >>>>are a good idea.
> > > > >>>>
> > > > >>>>
> > > > >Should be primitives, as object creation needs to be avoided.
> > > > >
> > > > >
> > > > >
> > > > >>It depends on how the methods are implemented.  The way I did
it
> > > > >>allowed me to implement the majority of the
> > > > java.lang.Number methods
> > > > >>in the abstract MutableNumber class, so each specific type
> > > > didn't have
> > > > >>a lot to do.
> > > > >>
> > > > >>
> > > > >This caused problems in the old (deprecated) implementation of
> > > > >NumberRange. Although annoying to code, special primitive specific
> > > > >subclasses are better
> > > > >
> > > > >
> > > > >
> > > > >>>*) How exactly should equals() work [I'm ignoring it for
> > > > the moment]
> > > > >>>
> > > > >>>
> > > > >>>>I made it expect a Number:
> > > > >>>>
> > > > >>>>boolean equals(Object o) {
> > > > >>>>return doubleValue() == ((Number)o).doubleValue()
> > > > >>>>}
> > > > >>>>
> > > > >>>>
> > > > >Danger with this is that the equals() isn't reflective. Comparing
a
> > > > >MutableInteger to a Integer would suceed or fail based on
> > > > which was on
> > > > >the left hand side.
> > > > >
> > > > >
> > > > >Finally, we might want to consider the role of [primitives] here.
> > > > >Perhaps these classes belong there?
> > > > >
> > > > >Stephen
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> 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