RE: [lang] MutableNumber (WAS: RE: [lang] Mutable type casts and MutableNumber)

[Gary Gregory <gg...@seagullsoftware.com>]

I think there is value indeed to a MutableNumber class and or interface
if you compare Number to the mutable classes that wrap number
primitives. 

In particular, Number declares all of the conversion methods like
byteValue(), intValue(), etc. Number provides default implementation for
byteValue() and shortValue() while other conversion methods are
abstract. 

If you look at MutableByte, you see for example byteValue() and
doubleValue(). But if you look at MutableDouble, you see doubleValue()
but no byteValue(), which is inconsistent. Having a superclass which
parallels Number would formalize and enforce these contracts.

There are such inconsistencies in all the Mutable classes :-(

IMHO this is a positive argument for MutableNumber (or AbstractNumber if
you prefer to keep MutableNumber as an interface).

Gary

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Thursday, September 30, 2004 16:15
> To: Jakarta Commons Developers List
> Subject: Re: [lang] Mutable type casts and MutableNumber
> 
> From: "matthew.hawthorne" <ma...@apache.org>
> > Gary Gregory wrote:
> > > 1st minor: there are a bunch of unnecessary type-casts, I'd like
to
> > > remove those if no one objects.
> +1
> 
> > > 2nd: There is no MutableNumber class. It seems to me that the
mutable
> > > number classes are paralle to java.lang.Number classes and should
> > > therefore also be subclasssed from a MutableNumber.
> >
> > Originally, there was such a class, but after some analysis and
> > refactoring, it wasn't really doing anything and was nominated for
> > removal.  However, I understand your point.  If MutableNumber were
to be
> > resurrected, it would serve only as a marker interface.  I'm fine
with
> that.
> -1, we shouldn't add classes that don't add value to lang.
> 
> 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: [lang] MutableNumber (WAS: RE: [lang] Mutable type casts and MutableNumber)

[Stephen Colebourne <sc...@btopenworld.com>]

This sounds like we should add the missing methods. MutableNumber is only
worth adding if someone is going to hold a variable reference as a mutable
Number, and I can't see the use case for that (over and above mutable
Object)

Stephen

From: "Gary Gregory" <gg...@seagullsoftware.com>
In particular, Number declares all of the conversion methods like
byteValue(), intValue(), etc. Number provides default implementation for
byteValue() and shortValue() while other conversion methods are
abstract.

If you look at MutableByte, you see for example byteValue() and
doubleValue(). But if you look at MutableDouble, you see doubleValue()
but no byteValue(), which is inconsistent. Having a superclass which
parallels Number would formalize and enforce these contracts.

There are such inconsistencies in all the Mutable classes :-(

IMHO this is a positive argument for MutableNumber (or AbstractNumber if
you prefer to keep MutableNumber as an interface).

Gary

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Thursday, September 30, 2004 16:15
> To: Jakarta Commons Developers List
> Subject: Re: [lang] Mutable type casts and MutableNumber
>
> From: "matthew.hawthorne" <ma...@apache.org>
> > Gary Gregory wrote:
> > > 1st minor: there are a bunch of unnecessary type-casts, I'd like
to
> > > remove those if no one objects.
> +1
>
> > > 2nd: There is no MutableNumber class. It seems to me that the
mutable
> > > number classes are paralle to java.lang.Number classes and should
> > > therefore also be subclasssed from a MutableNumber.
> >
> > Originally, there was such a class, but after some analysis and
> > refactoring, it wasn't really doing anything and was nominated for
> > removal.  However, I understand your point.  If MutableNumber were
to be
> > resurrected, it would serve only as a marker interface.  I'm fine
with
> that.
> -1, we shouldn't add classes that don't add value to lang.
>
> 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