Steve, 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? -- John -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
