You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <ba...@generationjava.com> on 2002/10/11 22:13:41 UTC
[lang] Ideas for Lang
Here's my list of things I mean to get around to adding soon:
1) Notifier class. I need a better name for this. Basically it's a helper
that uses reflection [used to use Notifiable interface, but I decided it
wasn't worth it, possibly wants to do both] to help a developer create an
event/listener list.
It handles the notifying and the queueing etc and the developer just has
to tell it what method or Listener to use [or both if Listener has
multiple method signatures].
2) Mutable primitive classes. Pondered this at the hospital today. Do we
want such things? new MutableInteger(); mi.setValue(42); etc. Same for
MutableString.
3) Constant. I'm still unsure if this is good or not :) It's been in and
out and in etc. My reasons for deciding it was shit was cuz I wanted to
use == when I initially grew to love it and RMI/Java means I have to use
.equals. But Enum makes that same choice. So is a simple-enum concept
needed.
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].
5) StopWatch. Currently this is in [util], but as its basically a wrapper
for System.currentLongTimeBlah I thought I'd mention it.
That's all that's springing to mind right now.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Ideas for Lang
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 14 Oct 2002, John Yu wrote:
> > > > 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?
> >
> >Possibly, though it isn't semantically. Assuming there's a need for a Pair
> >class, using DefaultMapEntry would not fulfill it, even if the
> >functionality were the same.
> >
> >My vague view being that things can be syntactically the same but
> >semantically different.
>
>
> You lost me.
> Could you elaborate? What semantics you're referring to in Pair?
Erm.. pass? :)
I was hoping there might be a good Lisp fanatic or something with some
reasons for why a Pair object would be very useful. I seem to recall
reading someone's blog opining for a Pair class.
The semantic bit was... I think there are many places where someone would
like to use a Pair and not a DefaultMapEntry. ie) They're not dealing with
Map.Entry functionality.
[One of the dangerous parts of suggesting ideas you don't believe in a lot
yourself :) ] Similar for the Mutable-primitives. I often find a point in
code where I think, "wish I could set the Integer", but then I get around
it somehow without much effort.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Ideas for Lang
Posted by John Yu <jo...@scioworks.com>.
At 12:18 pm 14-10-2002, you wrote:
> >
> > I suppose what you have in mind is MutableString extends java.util.String.
>
>String is final. Same for all/most of the Immutable painful things.
Oops, missed the obvious... ;-p
> > > 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?
>
>Possibly, though it isn't semantically. Assuming there's a need for a Pair
>class, using DefaultMapEntry would not fulfill it, even if the
>functionality were the same.
>
>My vague view being that things can be syntactically the same but
>semantically different.
You lost me.
Could you elaborate? What semantics you're referring to in Pair?
--
John Yu
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Ideas for Lang
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 14 Oct 2002, John Yu wrote:
> Steve,
>
> An initial thought:
>
> I suppose what you have in mind is MutableString extends java.util.String.
String is final. Same for all/most of the Immutable painful things.
> > 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?
Possibly, though it isn't semantically. Assuming there's a need for a Pair
class, using DefaultMapEntry would not fulfill it, even if the
functionality were the same.
My vague view being that things can be syntactically the same but
semantically different.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Ideas for Lang
Posted by John Yu <jo...@scioworks.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Ideas for Lang
Posted by Steve Downey <st...@netfolio.com>.
>
> > > 5) StopWatch. Currently this is in [util], but as its basically a
> > > wrapper for System.currentLongTimeBlah I thought I'd mention it.
> >
> > Considering how often I write stopwatches inline, I think it sounds
> > useful. It's not that it's hard, it's that it's repetetetetive.
>
> Yep. It was in GenJavaCore and I never used it. Then I found out the guy
> who sits opposite me was using it constantly...
>
Thinking about it, I used to have one that used JNI to get access to a Windows
high performance multimedia timer. Clock ticks in the micro-second range. I
have no idea where the code is now, but I could probably recreate it.
I was working on comparing CORBA, RMI, COM and local VM calls. Plus local
machine vs networked. No real surprises in the answers. But having hard
numbers gave me nice stick to beat developers with when they wanted to create
a remote String/Integer/Double/etc implementation.
> Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Ideas for Lang
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Steve Downey" <st...@netfolio.com>
> 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?
And then you'd have a Swing model that binds the MutableString into the GUI
seemlessly....
See http://www.joda.org. I've already coded this.
Now, I reckon Joda might do with a little simplification, but the basic
stuff is there.
StringProperty == MutableString
IntegerProperty == MutableInteger
etc.
Swing GUI models written for the basics, text, radio buttons etc.
However, I think that the full implications of this are much greater than
[lang] should be dealing with.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Ideas for Lang
Posted by Steve Downey <st...@netfolio.com>.
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?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Ideas for Lang
Posted by Henri Yandell <ba...@generationjava.com>.
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 :)
> > 3) Constant. I'm still unsure if this is good or not :) It's been in and
> > out and in etc. My reasons for deciding it was shit was cuz I wanted to
> > use == when I initially grew to love it and RMI/Java means I have to use
> > .equals. But Enum makes that same choice. So is a simple-enum concept
> > needed.
> >
> I think Enum lets you use == as well as equals(). At least, it works for
> serialization. Am I missing something?
ClassLoaders I think.
> > 5) StopWatch. Currently this is in [util], but as its basically a wrapper
> > for System.currentLongTimeBlah I thought I'd mention it.
> >
> Considering how often I write stopwatches inline, I think it sounds useful.
> It's not that it's hard, it's that it's repetetetetive.
Yep. It was in GenJavaCore and I never used it. Then I found out the guy
who sits opposite me was using it constantly...
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Ideas for Lang
Posted by Steve Downey <st...@netfolio.com>.
On Friday 11 October 2002 04:13 pm, Henri Yandell wrote:
> Here's my list of things I mean to get around to adding soon:
>
> 1) Notifier class. I need a better name for this. Basically it's a helper
> that uses reflection [used to use Notifiable interface, but I decided it
> wasn't worth it, possibly wants to do both] to help a developer create an
> event/listener list.
>
> It handles the notifying and the queueing etc and the developer just has
> to tell it what method or Listener to use [or both if Listener has
> multiple method signatures].
>
This sounds interesting and useful.
> 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.
> 3) Constant. I'm still unsure if this is good or not :) It's been in and
> out and in etc. My reasons for deciding it was shit was cuz I wanted to
> use == when I initially grew to love it and RMI/Java means I have to use
> .equals. But Enum makes that same choice. So is a simple-enum concept
> needed.
>
I think Enum lets you use == as well as equals(). At least, it works for
serialization. Am I missing 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].
>
> 5) StopWatch. Currently this is in [util], but as its basically a wrapper
> for System.currentLongTimeBlah I thought I'd mention it.
>
Considering how often I write stopwatches inline, I think it sounds useful.
It's not that it's hard, it's that it's repetetetetive.
> That's all that's springing to mind right now.
>
> Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Ideas for Lang
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Henri Yandell" <ba...@generationjava.com>
> 1) Notifier class. I need a better name for this. Basically it's a helper
> that uses reflection [used to use Notifiable interface, but I decided it
> wasn't worth it, possibly wants to do both] to help a developer create an
> event/listener list.
>
> It handles the notifying and the queueing etc and the developer just has
> to tell it what method or Listener to use [or both if Listener has
> multiple method signatures].
Not sure how this fits in with either the reflection stuff in [lang] or the
new [klass]. In fact it sounds more like a [pattern] thing. Which of course
raises another debate that needs to happen...
> 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 don't know whether these stand alone as independent classes. These classes
are similar to those that exist in my own Joda project. If we are to go down
this route, I would like to see use define interfaces as well -
ReadableInteger and ReadWriteableInteger.
> 3) Constant. I'm still unsure if this is good or not :) It's been in and
> out and in etc. My reasons for deciding it was shit was cuz I wanted to
> use == when I initially grew to love it and RMI/Java means I have to use
> .equals. But Enum makes that same choice. So is a simple-enum concept
> needed.
I'd need convincing that having two enum techniques in the same project is a
good idea.
> 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].
Definitely should be in. It must implement Map.Entry.
> 5) StopWatch. Currently this is in [util], but as its basically a wrapper
> for System.currentLongTimeBlah I thought I'd mention it.
I haven't looked at it, so can't comment.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [lang] Ideas for Lang
Posted by Steven Caswell <st...@caswell.name>.
> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Friday, October 11, 2002 3:14 PM
> To: Jakarta Commons Developers List
> Subject: [lang] Ideas for Lang
>
>
>
> Here's my list of things I mean to get around to adding soon:
>
> 1) Notifier class. I need a better name for this. Basically
> it's a helper that uses reflection [used to use Notifiable
> interface, but I decided it wasn't worth it, possibly wants
> to do both] to help a developer create an event/listener list.
>
> It handles the notifying and the queueing etc and the
> developer just has to tell it what method or Listener to use
> [or both if Listener has multiple method signatures].
>
> 2) Mutable primitive classes. Pondered this at the hospital
> today. Do we
> want such things? new MutableInteger(); mi.setValue(42);
> etc. Same for
> MutableString.
>
Sounds interesting.
> 3) Constant. I'm still unsure if this is good or not :) It's
> been in and out and in etc. My reasons for deciding it was
> shit was cuz I wanted to use == when I initially grew to love
> it and RMI/Java means I have to use .equals. But Enum makes
> that same choice. So is a simple-enum concept needed.
I haven't had a chance to look at enum yet (though I will), but I do
desire some kind of simple constant. I don't necessarily using .equals,
I just don't want to have to recreate classes every time I use the
pattern (which is quite often).
>
> 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].
Can you elaborate on Par a litte more?
>
> 5) StopWatch. Currently this is in [util], but as its
> basically a wrapper for System.currentLongTimeBlah I thought
> I'd mention it.
>
> That's all that's springing to mind right now.
>
> Hen
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
My list. Nothing earth shaking, just simple stuff that seems to be
useful.
1. I'm planning soon to work on the CalendarUtils a bit and get that
ready for primetime.
2. Along the same lines as the Mutable primitive classes, I've got a
ComparableBoolean I want to throw in.
3. I also want to work on getting [io] promoted to a proper citizen.
This is not [lang], but it might make sense to bring the [io] stuff into
[lang] if there is not enough [io] momentum.
4. Got a few StringUtils additions.
Steven Caswell
steven@caswell.name
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>