> *) 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
