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 Mon, 01 Sep 2003 02:30:49 GMT
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
> 

Mime
View raw message