You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2003/08/28 23:47:27 UTC
[lang] TODO for 2.1
Proposed TODO list for [lang] 2.1:
Essentials?:
- Maven website
- StringUtils.ordinalIndexOf()
- StringBuffer replacement
- Remove lang.reflect to [reflect]
Possibilities?::
- Mutable Number classes
- Identifiers?
- StringTokenizer replacement
I feel that I've missed things. Anything else to add? (Of course [lang]
should stabilise in size, otherwise it would fail in its mission of being
simple and highly useful)
Stephen
PS. While [lang] is in limbo waiting for the build, if any committers want
to help review [collections] for an upcoming release, I'd welcome it ;-))
Re: Mutables Was: [lang] TODO for 2.1
Posted by __matthewHawthorne <mh...@alumni.pitt.edu>.
Here's an example of the current state:
MutableInteger
// from Mutable
void setValue(Object)
Object getValue()
// from MutableNumber
Number getNumber()
void setNumber(Number)
// Subclass specific
setValue(int)
I was assuming that we wouldn't need a [int getIntValue()] method, since
it inherits [int intValue()] from java.lang.Number. But do we need this
method, in order to be JavaBean compliant?
Also, instead of [Integer intNumber()], I was thinking
[Object getValue()] could be used, and casted to the corresponding type.
Do you think that the explicit object accessor is necessary?
I don't understand your suggestion about overflows, can you elaborate?
On Tue, 2003-09-02 at 15:51, Stephen Colebourne wrote:
> +0.8 ;-)
> you might want to list the full API for MutableInteger just to be
> sure...mine below:
> On Mutable (interface):
> setValue(Object)
> getValue()
>
> On MutableNumber (interface):
> getNumber()
> setNumber(Number)
>
> shortNumber() - maybe only on implementation?
> getShortValue() - synonm for JavaBean tools
> setShortValue(short)
> etc. for int, long, float, double
>
> I suggest you may want two implementations eventually for overflow
> (short) Integer.MAX_VALUE:
> 1) works with a silly result
> 2) throws ArithmeticException (or a new OverflowException)
>
> Stephen
>
> ----- Original Message -----
> From: "__matthewHawthorne" <mh...@alumni.pitt.edu>
> > 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" <mh...@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
>
Re: Mutables Was: [lang] TODO for 2.1
Posted by Stephen Colebourne <sc...@btopenworld.com>.
+0.8 ;-)
you might want to list the full API for MutableInteger just to be
sure...mine below:
On Mutable (interface):
setValue(Object)
getValue()
On MutableNumber (interface):
getNumber()
setNumber(Number)
shortNumber() - maybe only on implementation?
getShortValue() - synonm for JavaBean tools
setShortValue(short)
etc. for int, long, float, double
I suggest you may want two implementations eventually for overflow
(short) Integer.MAX_VALUE:
1) works with a silly result
2) throws ArithmeticException (or a new OverflowException)
Stephen
----- Original Message -----
From: "__matthewHawthorne" <mh...@alumni.pitt.edu>
> 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" <mh...@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
>
Re: Mutables Was: [lang] TODO for 2.1
Posted by __matthewHawthorne <mh...@alumni.pitt.edu>.
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" <st...@mungoknotwise.com>
> > To: "'Jakarta Commons Developers List'" <co...@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" <mh...@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
>
Re: Mutables Was: [lang] TODO for 2.1
Posted by Henri Yandell <ba...@generationjava.com>.
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" <st...@mungoknotwise.com>
> To: "'Jakarta Commons Developers List'" <co...@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" <mh...@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
>
Re: Mutables Was: [lang] TODO for 2.1
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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" <st...@mungoknotwise.com>
To: "'Jakarta Commons Developers List'" <co...@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" <mh...@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
>
RE: Mutables Was: [lang] TODO for 2.1
Posted by Steven Caswell <st...@mungoknotwise.com>.
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" <mh...@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
>
>
>
>
Re: Mutables Was: [lang] TODO for 2.1
Posted by __matthewHawthorne <mh...@alumni.pitt.edu>.
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" <mh...@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
>
>
>
>
>
>
Re: Mutables Was: [lang] TODO for 2.1
Posted by __matthewHawthorne <mh...@alumni.pitt.edu>.
> Another question, should MutableDouble provide all of DoubleUtils [okay,
> NumberUtils, I'm trying to think in patterns] as instance methods?
I don't think so. NumberUtils methods which operate on a Number should
be able to use a MutableNumber in the same way.
As far as whether to put these classes in [lang] or [primitives], it all
depends on how we define the purpose of the classes. Are they simple
language extensions, or are they a bridge between the primitive and
Object worlds? They both make sense to me, so if you're leaning towards
[primitives], let's put them there.
On Tue, 2003-09-02 at 06:29, Henri Yandell wrote:
> On Mon, 1 Sep 2003, Stephen Colebourne wrote:
>
> > > > *) 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.
>
> I think it depends on how we do the methods. If we delegate to another
> class, Double or DoubleUtils, then it ought to be the wrapper as there
> will be too much object creation. If we implement it all ourselves, then
> it should be primitive.
>
> > > 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
>
> Much harder for us to keep in sync with Sun though. I guess the Unit Test
> could be created to test sync-ness in a nice general way.
>
> Another question, should MutableDouble provide all of DoubleUtils [okay,
> NumberUtils, I'm trying to think in patterns] as instance methods?
>
> > > > *) 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.
>
> Yeah. I expect equals() to be the main pain in the arse.
>
> > Finally, we might want to consider the role of [primitives] here. Perhaps
> > these classes belong there?
>
> I'm +1 for them going into primitives.
>
> Hen
>
RE: Mutables Was: [lang] TODO for 2.1
Posted by Steven Caswell <st...@mungoknotwise.com>.
Inline below
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: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Tuesday, September 02, 2003 8:29 AM
> To: Jakarta Commons Developers List
> Cc: mhawthorne@alumni.pitt.edu
> Subject: Re: Mutables Was: [lang] TODO for 2.1
>
>
>
>
> On Mon, 1 Sep 2003, Stephen Colebourne wrote:
>
> > > > *) 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.
>
> I think it depends on how we do the methods. If we delegate
> to another class, Double or DoubleUtils, then it ought to be
> the wrapper as there will be too much object creation. If we
> implement it all ourselves, then it should be primitive.
>
> > > 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
>
> Much harder for us to keep in sync with Sun though. I guess
> the Unit Test could be created to test sync-ness in a nice
> general way.
>
> Another question, should MutableDouble provide all of
> DoubleUtils [okay, NumberUtils, I'm trying to think in
> patterns] as instance methods?
>
> > > > *) 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.
>
> Yeah. I expect equals() to be the main pain in the arse.
The equals() method for the JDK wrappers insist on the class being the same.
So, for example, given:
Short s = new Short(45)
Long l = new Long(45)
Double d = new Double(45.0)
Then
s.equals(l) returns false
l.equals(d) returns false
d.equals(s) returns false
Etc.
So if these are intended to be mutable extensions of the java.lang wrappers,
we might want to stick to that convention.
>
> > Finally, we might want to consider the role of [primitives] here.
> > Perhaps these classes belong there?
>
> I'm +1 for them going into primitives.
Except that if these are intended to be mutable extensions of the JDK
wrappers, which are in java.lang, would [lang] be more appropriate? I'd be
more inclined to look for wrapper-based functionality that enhances
java.lang wrappers in [lang] than in [primitives].
And I'm +1 on MutableXxx rather than MXxx. More descriptive.
>
> Hen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
Re: Mutables Was: [lang] TODO for 2.1
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 1 Sep 2003, Stephen Colebourne wrote:
> > > *) 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.
I think it depends on how we do the methods. If we delegate to another
class, Double or DoubleUtils, then it ought to be the wrapper as there
will be too much object creation. If we implement it all ourselves, then
it should be primitive.
> > 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
Much harder for us to keep in sync with Sun though. I guess the Unit Test
could be created to test sync-ness in a nice general way.
Another question, should MutableDouble provide all of DoubleUtils [okay,
NumberUtils, I'm trying to think in patterns] as instance methods?
> > > *) 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.
Yeah. I expect equals() to be the main pain in the arse.
> Finally, we might want to consider the role of [primitives] here. Perhaps
> these classes belong there?
I'm +1 for them going into primitives.
Hen
Re: Mutables Was: [lang] TODO for 2.1
Posted by Stephen Colebourne <sc...@btopenworld.com>.
----- Original Message -----
From: "__matthewHawthorne" <mh...@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
Re: Mutables Was: [lang] TODO for 2.1
Posted by __matthewHawthorne <mh...@alumni.pitt.edu>.
> *) Is a .mutable subpackage okay?
> > I prefer lang.math
>
> Boolean? Byte? String? None of these belong in lang.math.
You're right... I've never really used bytes, so I wasn't sure where
they would fall. I didn't create a mutable boolean since someone
suggested otherwise, but if others think it's useful I'm +1 for adding
it... I think it would be useful.
I was initially confused by the concept of a mutable String, but now I
think I get it.
> *) 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.
>
> Sounds good. The bad side of using primitives is that in many cases we
> should use the method in the Xxxx class implementation. Having a wrapped
> Xxxx makes this easier.
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.
If we decide that there is a better way it may be easier to do what
you're saying, for example, MutableInteger delegates the majority of
methods to an Integer instance var.
> *) 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()
> > }
> >
> > I'm not sure if this is a good way to do it or not. I think my tests
> > were pretty thorough, and it seemed OK.
>
> I like it. Very simple. However it needs a little type checking.
> Currently, applying the same concept to Integer means that we'd have 'int's
> that equal 'double's.
>
> However, it also will fall over with a class not found when 'o' is another
> Mutable instance, when the superclass is final. Namely String/Boolean.
It depends on how we define equality. The code shown above treats ints
and doubles as equal that have similar values (5 vs. 5.0). Is this OK?
I'm not sure.
The behavior of java.lang.Number extensions is indeed a lot different
than booleans or strings. I think it's OK to throw a ClassCastException
when attempting to compare a MutableInteger to a MutableBoolean... but
I'm not sure how others feel. It depends on how much work in involved
in comparing 2 objects of different types.
On Sun, 2003-08-31 at 19:53, Henri Yandell wrote:
> On 31 Aug 2003, __matthewHawthorne wrote:
>
> > About a week ago, I submitted an initial implementation of mutable
> > numbers, in a bug report:
> >
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=22717
> >
> > Another developer noticed that similar classes were recently added to
> > Geronimo. More details are in the bug report dialog.
>
> Cool. I'm usually guilty of not checking bugzilla enough, so will go read
> it :)
>
> > As a start, I suggest that we all take a look at these Geronimo classes,
> > as well as the classes that I've written, and see what everyone thinks.
>
> Sounds good.
>
> > My goal was to make the classes as small and simple as possible. I
> > overrode all of the methods from java.lang.Number such as byteValue()
> > and intValue(), and also added Object versions of these, such as
> > byteObject() and intObject().
>
> Small = good. Don't want to have lots of repitive code to maintain.
>
> > Having looked at the Geronimo implementation, and seeing the code that
> > Henri proposed, I think it may be better to create a Mutable interface,
> > with the following methods:
> >
> > void setValue(Object)
> > Object getValue()
>
> +1
>
> > My implementation also contains primitive setters, such as:
> >
> > setValue(double)
>
> [What I called Helper methods]
>
> > *) Should helper mutable methods exist?
> > What do you mean by this?
>
> setValue(double) etc.
>
> > *) Should static methods from the Boolean class be implemented?
> > -1, I don't think so.
>
> I'm thinking the same.
>
> > *) Should the naming convention be MXxxx
> > I think MutableXXX is clearer, but either are OK.
>
> Am happy with either.
>
> > *) 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.
>
> Sounds good. The bad side of using primitives is that in many cases we
> should use the method in the Xxxx class implementation. Having a wrapped
> Xxxx makes this easier.
>
> > *) Is a .mutable subpackage okay?
> > I prefer lang.math
>
> Boolean? Byte? String? None of these belong in lang.math.
>
> > *) 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()
> > }
> >
> > I'm not sure if this is a good way to do it or not. I think my tests
> > were pretty thorough, and it seemed OK.
>
> I like it. Very simple. However it needs a little type checking.
> Currently, applying the same concept to Integer means that we'd have 'int's
> that equal 'double's.
>
> However, it also will fall over with a class not found when 'o' is another
> Mutable instance, when the superclass is final. Namely String/Boolean.
>
> Hen
>
Re: Mutables Was: [lang] TODO for 2.1
Posted by Henri Yandell <ba...@generationjava.com>.
On 31 Aug 2003, __matthewHawthorne wrote:
> About a week ago, I submitted an initial implementation of mutable
> numbers, in a bug report:
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=22717
>
> Another developer noticed that similar classes were recently added to
> Geronimo. More details are in the bug report dialog.
Cool. I'm usually guilty of not checking bugzilla enough, so will go read
it :)
> As a start, I suggest that we all take a look at these Geronimo classes,
> as well as the classes that I've written, and see what everyone thinks.
Sounds good.
> My goal was to make the classes as small and simple as possible. I
> overrode all of the methods from java.lang.Number such as byteValue()
> and intValue(), and also added Object versions of these, such as
> byteObject() and intObject().
Small = good. Don't want to have lots of repitive code to maintain.
> Having looked at the Geronimo implementation, and seeing the code that
> Henri proposed, I think it may be better to create a Mutable interface,
> with the following methods:
>
> void setValue(Object)
> Object getValue()
+1
> My implementation also contains primitive setters, such as:
>
> setValue(double)
[What I called Helper methods]
> *) Should helper mutable methods exist?
> What do you mean by this?
setValue(double) etc.
> *) Should static methods from the Boolean class be implemented?
> -1, I don't think so.
I'm thinking the same.
> *) Should the naming convention be MXxxx
> I think MutableXXX is clearer, but either are OK.
Am happy with either.
> *) 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.
Sounds good. The bad side of using primitives is that in many cases we
should use the method in the Xxxx class implementation. Having a wrapped
Xxxx makes this easier.
> *) Is a .mutable subpackage okay?
> I prefer lang.math
Boolean? Byte? String? None of these belong in lang.math.
> *) 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()
> }
>
> I'm not sure if this is a good way to do it or not. I think my tests
> were pretty thorough, and it seemed OK.
I like it. Very simple. However it needs a little type checking.
Currently, applying the same concept to Integer means that we'd have 'int's
that equal 'double's.
However, it also will fall over with a class not found when 'o' is another
Mutable instance, when the superclass is final. Namely String/Boolean.
Hen
Re: Mutables Was: [lang] TODO for 2.1
Posted by __matthewHawthorne <mh...@alumni.pitt.edu>.
About a week ago, I submitted an initial implementation of mutable
numbers, in a bug report:
http://issues.apache.org/bugzilla/show_bug.cgi?id=22717
Another developer noticed that similar classes were recently added to
Geronimo. More details are in the bug report dialog.
As a start, I suggest that we all take a look at these Geronimo classes,
as well as the classes that I've written, and see what everyone thinks.
My goal was to make the classes as small and simple as possible. I
overrode all of the methods from java.lang.Number such as byteValue()
and intValue(), and also added Object versions of these, such as
byteObject() and intObject().
Having looked at the Geronimo implementation, and seeing the code that
Henri proposed, I think it may be better to create a Mutable interface,
with the following methods:
void setValue(Object)
Object getValue()
My implementation also contains primitive setters, such as:
setValue(double)
Actually, I think I only implemented the double version, allowing an
upcast to occur for all smaller types. I don't think this is the best
way, not only for clarity's sake, but also for the possible overhead of
upcasting. This can be easily improved.
To answer the questions more directly:
*) Should there be a Mutable interface?
+1, details above
*) Should helper mutable methods exist?
What do you mean by this?
*) Should static methods from the Boolean class be implemented?
-1, I don't think so.
*) Should the naming convention be MXxxx
I think MutableXXX is clearer, but either are OK.
*) 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.
*) Is a .mutable subpackage okay?
I prefer lang.math
*) 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()
}
I'm not sure if this is a good way to do it or not. I think my tests
were pretty thorough, and it seemed OK.
Alright, let's hear some more ideas.
On Sun, 2003-08-31 at 18:58, Henri Yandell wrote:
> On Sun, 31 Aug 2003, Henri Yandell wrote:
>
> >
> >
> > On Thu, 28 Aug 2003, Stephen Colebourne wrote:
> >
> > > - Mutable Number classes
>
> Assuming we don't already have the mutable code in another project, I've
> put together a simple MBoolean class to act as a framework on which to
> argue. Code follows, then questions:
>
> ***********************************
> package org.apache.commons.lang.mutable;
>
> import java.io.Serializable;
>
> public final class MBoolean implements Serializable, Mutable {
>
> public static final MBoolean TRUE = new MBoolean(true);
> public static final MBoolean FALSE = new MBoolean(false);
> public static final Class TYPE = MBoolean.class;
>
> private Boolean value;
>
> /// Start copy of Boolean 'interface'
> public MBoolean(boolean b) {
> this.value = new Boolean(b);
> }
> public MBoolean(String str) {
> this.value = new Boolean(str);
> }
>
> public boolean booleanValue() {
> return this.value.booleanValue();
> }
> public static MBoolean valueOf(boolean b) {
> return b ? TRUE : FALSE;
> }
> public static MBoolean valueOf(String str) {
> // does Boolean return TRUE/FALSE here? Bet it does.
> Boolean b = new Boolean(str);
> return valueOf(b.booleanValue());
> }
> public static String toString(boolean b) {
> return b ? TRUE.toString() : FALSE.toString();
> }
> public String toString() {
> return this.value.toString();
> }
> public int hashCode() {
> return this.hashCode.toString();
> }
> public boolean equals(Object obj) {
> // Implementation needs thought....
> }
> public static boolean getBoolean(String str) {
> return Boolean.getBoolean(str);
> }
> // End of copy of Boolean 'interface'
>
> // Start of Mutable interface
> public void setValue(Object obj) {
> if(obj instanceof Boolean) {
> this.value = (Boolean)obj;
> } else {
> throw new IllegalArgumentException("Cannot set an MBoolean
> with a no
> n-Boolean. ");
> }
> }
> // End of Mutable interface
>
> // Helper methods
> public void setValue(boolean b) {
> this.value = new Boolean(b);
> }
>
> }
>
> ***********************************************
>
> Things that I think are worth arguing:
>
> *) Should there be a Mutable interface?
> *) Should helper mutable methods exist?
> *) Should static methods from the Boolean class be implemented?
> *) Should the naming convention be MXxxx
> *) Should the MXxxx decorate an Xxxx or an xxxx. [ie primitive or wrapper?]
> *) Is a .mutable subpackage okay?
> *) How exactly should equals() work [I'm ignoring it for the moment]
>
> Hen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Mutables Was: [lang] TODO for 2.1
Posted by Henri Yandell <ba...@generationjava.com>.
On Sun, 31 Aug 2003, Henri Yandell wrote:
>
>
> On Thu, 28 Aug 2003, Stephen Colebourne wrote:
>
> > - Mutable Number classes
Assuming we don't already have the mutable code in another project, I've
put together a simple MBoolean class to act as a framework on which to
argue. Code follows, then questions:
***********************************
package org.apache.commons.lang.mutable;
import java.io.Serializable;
public final class MBoolean implements Serializable, Mutable {
public static final MBoolean TRUE = new MBoolean(true);
public static final MBoolean FALSE = new MBoolean(false);
public static final Class TYPE = MBoolean.class;
private Boolean value;
/// Start copy of Boolean 'interface'
public MBoolean(boolean b) {
this.value = new Boolean(b);
}
public MBoolean(String str) {
this.value = new Boolean(str);
}
public boolean booleanValue() {
return this.value.booleanValue();
}
public static MBoolean valueOf(boolean b) {
return b ? TRUE : FALSE;
}
public static MBoolean valueOf(String str) {
// does Boolean return TRUE/FALSE here? Bet it does.
Boolean b = new Boolean(str);
return valueOf(b.booleanValue());
}
public static String toString(boolean b) {
return b ? TRUE.toString() : FALSE.toString();
}
public String toString() {
return this.value.toString();
}
public int hashCode() {
return this.hashCode.toString();
}
public boolean equals(Object obj) {
// Implementation needs thought....
}
public static boolean getBoolean(String str) {
return Boolean.getBoolean(str);
}
// End of copy of Boolean 'interface'
// Start of Mutable interface
public void setValue(Object obj) {
if(obj instanceof Boolean) {
this.value = (Boolean)obj;
} else {
throw new IllegalArgumentException("Cannot set an MBoolean
with a no
n-Boolean. ");
}
}
// End of Mutable interface
// Helper methods
public void setValue(boolean b) {
this.value = new Boolean(b);
}
}
***********************************************
Things that I think are worth arguing:
*) Should there be a Mutable interface?
*) Should helper mutable methods exist?
*) Should static methods from the Boolean class be implemented?
*) Should the naming convention be MXxxx
*) Should the MXxxx decorate an Xxxx or an xxxx. [ie primitive or wrapper?]
*) Is a .mutable subpackage okay?
*) How exactly should equals() work [I'm ignoring it for the moment]
Hen
Re: [lang] TODO for 2.1
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 28 Aug 2003, Stephen Colebourne wrote:
> Proposed TODO list for [lang] 2.1:
>
> Essentials?:
>
> - Maven website
+1
> - StringUtils.ordinalIndexOf()
Will read the thread on this once 2.0 is out.
> - StringBuffer replacement
+1
> - Remove lang.reflect to [reflect]
+1
> Possibilities?::
>
> - Mutable Number classes
> - Identifiers?
> - StringTokenizer replacement
All good I think.
Hen
Re: [lang] TODO for 2.1
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Phil Steitz" <st...@yahoo.com>
> By "StringTokenizer replacement" are you referring to the request implied
> by #22692?
Yes, a tokenizer that can match by strings, not just characters, and with
many more options.Maybe someone already has such a thing we can grab???
> There are also some relatively minor checkstyle issues and it would be
good
> to do some performance testing and, if warranted, optimization.
+1
> Finally, I would like to fix the Fraction double factory method to either
> not use continued fractions or to improve the implementation. The private
> gcd method that this class uses should also probably be moved to
lang.math.
If you feel it could be better then fine. So far it passed the tests I wrote
so I'm not that bothered ;-)
> Phil
>
> P.S. I will have a look at [collections] this weekend
:-))
>
> --- Stephen Colebourne <sc...@btopenworld.com> wrote:
> > Proposed TODO list for [lang] 2.1:
> >
> > Essentials?:
> >
> > - Maven website
> > - StringUtils.ordinalIndexOf()
> > - StringBuffer replacement
> > - Remove lang.reflect to [reflect]
> >
> >
> > Possibilities?::
> >
> > - Mutable Number classes
> > - Identifiers?
> > - StringTokenizer replacement
> >
> >
> > I feel that I've missed things. Anything else to add? (Of course [lang]
> > should stabilise in size, otherwise it would fail in its mission of
being
> > simple and highly useful)
> >
> > Stephen
> > PS. While [lang] is in limbo waiting for the build, if any committers
> > want
> > to help review [collections] for an upcoming release, I'd welcome it
> > ;-))
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [lang] TODO for 2.1
Posted by Phil Steitz <st...@yahoo.com>.
Looks good.
By "StringTokenizer replacement" are you referring to the request implied
by #22692?
There are also some relatively minor checkstyle issues and it would be good
to do some performance testing and, if warranted, optimization.
Finally, I would like to fix the Fraction double factory method to either
not use continued fractions or to improve the implementation. The private
gcd method that this class uses should also probably be moved to lang.math.
Phil
P.S. I will have a look at [collections] this weekend
--- Stephen Colebourne <sc...@btopenworld.com> wrote:
> Proposed TODO list for [lang] 2.1:
>
> Essentials?:
>
> - Maven website
> - StringUtils.ordinalIndexOf()
> - StringBuffer replacement
> - Remove lang.reflect to [reflect]
>
>
> Possibilities?::
>
> - Mutable Number classes
> - Identifiers?
> - StringTokenizer replacement
>
>
> I feel that I've missed things. Anything else to add? (Of course [lang]
> should stabilise in size, otherwise it would fail in its mission of being
> simple and highly useful)
>
> Stephen
> PS. While [lang] is in limbo waiting for the build, if any committers
> want
> to help review [collections] for an upcoming release, I'd welcome it
> ;-))
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com