commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Yu <>
Subject Re: [lang] Ideas for Lang
Date Mon, 14 Oct 2002 02:48:18 GMT

At 04:48 am 13-10-2002, you wrote:
>On Friday 11 October 2002 07:49 pm, Henri Yandell wrote:
> > On Fri, 11 Oct 2002, Steve Downey wrote:
> > > > 2) Mutable primitive classes. Pondered this at the hospital today. Do
> > > > we want such things? new MutableInteger();   mi.setValue(42); etc. Same
> > > > for MutableString.
> > >
> > > I'm not so sure about Mutable value classes. I'd want to see a use case
> > > for them first. IOW, what does it gain over this.value = new Integer(42)?
> > > If there's shared mutable state, I think it's usually within the same
> > > class. I don't see the utility of a mutable Integer that's shared between
> > > unrelated classes. And within the same class, I'd think just using
> > > members is more natural.
> >
> > Yeah, my reaction was to think no. But then I decided that discussion on
> > it would be very interesting :)
> >
>I figured out what they are for.
>Let's say you have something observing a String, for display or whatever. If
>the value changes, you want the new value displayed. The entity doing the
>display shouldn't care what the String represents. So if it has a
>MutableString, and registers for notifications of changes of the
>MutableString, it can update whenever the String changes.
>They're kind of like Delegates for properties.
>What do you think?

An initial thought:

I suppose what you have in mind is MutableString extends java.util.String. 
However, doing this breaks the contract defined by java.util.String that it 
is immutable. (i.e. It is semantically inconsistent.) e.g. If an entity has 
a method which takes a String, it relies (implicitly) on the contract that 
the String will never change its value.

To put it another way, it should be String extends MutableString, not the 
other way round. (Just like Square extending Rectangle, the subtypes are 
always more restrictive.) The same thing applies to other possible mutable 
primitive classes.

If that's the case, (1) I can't see a way to "insert" new classes into 
JDK's existing class hierarchy (without raising a JSR ;-) (2) it is not 
applicable to your use case anymore.

Have I missed something?

 > 4) Pair. Is this Collections? Dunno. Anyway, pairs seem to be nice
 > sometimes. I only have one because I was porting the lisp examples to Java
 > from the lisp book [yep, i'm that sick].

Isn't o.a.c.collections.DefaultMapEntry, fulfilling the role of Pair?

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message