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 2003/08/19 05:40:34 UTC
[collections] Questions....
Few questions.
Firstly, SingletonIterator and SingletonListIterator seem quite similar.
Apart from the extra type of 'ListIterator', it appears that a
SingletonListIterator can do the job of a SingletonIterator in all jobs.
Could just remove SingleIterator.
Second question. What's ListIteratorWrapper useful for?
It seems to just let us throw a normal Iterator into something requiring
ListIterator-ness, except then it'll go ahead and throw exceptions on most
methods. So is it just an iterator that can get the previous element?
Next. MultiMap has a remove(Object, Object) contract and therefore is not
a tag interface as the javadoc states.
The javadoc for a priority queue does not explain what a priority
queue is.
FastXxx classes say that they are not cross-platform, but in no way
discuss which platforms they are targetted at. This makes these classes
useless except to the authors.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Questions....
Posted by Rich Dougherty <ri...@rd.gen.nz>.
On Wed, Aug 20, 2003 at 10:25:39AM -0400, Henri Yandell wrote:
> > > FastXxx classes say that they are not cross-platform, but in no way
> > > discuss which platforms they are targetted at. This makes these classes
> > > useless except to the authors.
> > IIRC, nobody can ever answer this question. It may be a theoretical risk, or
> > a real one. Who knows?
>
> Dunno. Hopefully someone on the project has a clue?
The Fast* classes provide a thread-safe wrapper around collection classes.
Their read operations are faster than the thos of the sychronizing wrappers
in the standard Java libraries. However, the write operations are slower.
This is because all state is stored in a single field. Read
operations can access this state without synchronization. Only write operations
are synchronized. The write operations update the state by copying it,
updating the copy, then replacing the original state with the copy. The copy
operation is atomic, so the classes are thread safe.
However on some platforms they may not behave as expected. As the JVM spec
is written, read operations in different threads may not notice when the
state is changed. This is because different threads are permitted to give
different values for non-volatile fields in unsynchronized code.
The read operations aren't synchronized and the field insn't volatile so the
read operations may not operate on the latest state.
I don't think this happens much in practice because most JVM implementations
always show the same value, even in different threads. However, the
possibility exists that the Fast* classes won't work as expected in some
JVMs.
I'm not very will connected to the net right now, so I haven't been able to
verify this, but I think that may be what whoever wrote that note was
talking about.
Rich
--
Rich Dougherty
http://www.rd.gen.nz/
Re: [collections] Questions....
Posted by Stephen Colebourne <sc...@btopenworld.com>.
So exacly what problem are we trying to solve by all discussing
SingletonIterator?
- It works
- It fulfills a need
- It can be javadoc'd simply
- Its probably already been released
I'm sure there are some javadoc improvements to make, but I don't want to
create work for ourselves.
[collections] has many other things on the TODO list:
MultiMap
http://issues.apache.org/bugzilla/show_bug.cgi?id=21030
http://issues.apache.org/bugzilla/show_bug.cgi?id=16465
Serializable
http://issues.apache.org/bugzilla/show_bug.cgi?id=18815
http://issues.apache.org/bugzilla/show_bug.cgi?id=18068
http://issues.apache.org/bugzilla/show_bug.cgi?id=16465
Properties
http://issues.apache.org/bugzilla/show_bug.cgi?id=19061
http://issues.apache.org/bugzilla/show_bug.cgi?id=17809
Primitive Map implementations
If anyone want to comment on these, help commit, help with patches feel
free. If you do, I suggest a separate thread and talking on the list first
;-)
Stephen
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
> On Tue, 19 Aug 2003, Stephen Colebourne wrote:
>
> > From: "Henri Yandell" <ba...@generationjava.com>
> > > Firstly, SingletonIterator and SingletonListIterator seem quite
similar.
> > > Apart from the extra type of 'ListIterator', it appears that a
> > > SingletonListIterator can do the job of a SingletonIterator in all
jobs.
> > > Could just remove SingleIterator.
> > True, but somebody may only want the Iterator interface to be
implemented.
> > By having both we give the user the flexibility to choose.
>
> Agreed. Trying to 'package' defensively :) SingletonListIterator could
> become a static on SingletonIterator:
> SingletonIterator.asListIterator(Object) or some such. Mainly just trying
> to make Collections easier to grokk.
>
> > > Second question. What's ListIteratorWrapper useful for?
> > > It seems to just let us throw a normal Iterator into something
requiring
> > > ListIterator-ness, except then it'll go ahead and throw exceptions on
most
> > > methods. So is it just an iterator that can get the previous element?
> > Yep, it allows forwards and backwards movement through any iterator, not
> > just list iterators. And no, I don't know why its useful.
>
> So basically a decorator pattern, but not a stunningly useful one.
>
> > > Next. MultiMap has a remove(Object, Object) contract and therefore is
not
> > > a tag interface as the javadoc states.
> > Actually MultiMap is a poor interface that probably should be changed.
It is
> > a difficult decision as we are not supposed to change interfaces, but it
is
> > perhaps unlikely that there are too many implementations of this one.
See
> > bugzilla.
>
> Agreed. My preference would be to remove MultiMap, rename MultiHashMap to
> MultiMap and then rewrite it to decorate a passed in Map. But I've said
> this before and not found the time to get stuck in.
>
> > > The javadoc for a priority queue does not explain what a priority
> > > queue is.
> > Not sure if I remember either.
>
> Heh. And we wonder why users are confused :)
>
> > > FastXxx classes say that they are not cross-platform, but in no way
> > > discuss which platforms they are targetted at. This makes these
classes
> > > useless except to the authors.
> > IIRC, nobody can ever answer this question. It may be a theoretical
risk, or
> > a real one. Who knows?
>
> Dunno. Hopefully someone on the project has a clue?
>
> Hen
>
>
> ---------------------------------------------------------------------
> 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: [collections] Questions....
Posted by Stephen Colebourne <sc...@btopenworld.com>.
So exacly what problem are we trying to solve by all discussing
SingletonIterator?
- It works
- It fulfills a need
- It can be javadoc'd simply
- Its probably already been released
I'm sure there are some javadoc improvements to make, but I don't want to
create work for ourselves.
[collections] has many other things on the TODO list:
MultiMap
http://issues.apache.org/bugzilla/show_bug.cgi?id=21030
http://issues.apache.org/bugzilla/show_bug.cgi?id=16465
Serializable
http://issues.apache.org/bugzilla/show_bug.cgi?id=18815
http://issues.apache.org/bugzilla/show_bug.cgi?id=18068
http://issues.apache.org/bugzilla/show_bug.cgi?id=16465
Properties
http://issues.apache.org/bugzilla/show_bug.cgi?id=19061
http://issues.apache.org/bugzilla/show_bug.cgi?id=17809
Primitive Map implementations
If anyone want to comment on these, help commit, help with patches feel
free. If you do, I suggest a separate thread and talking on the list first
;-)
Stephen
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
> On Tue, 19 Aug 2003, Stephen Colebourne wrote:
>
> > From: "Henri Yandell" <ba...@generationjava.com>
> > > Firstly, SingletonIterator and SingletonListIterator seem quite
similar.
> > > Apart from the extra type of 'ListIterator', it appears that a
> > > SingletonListIterator can do the job of a SingletonIterator in all
jobs.
> > > Could just remove SingleIterator.
> > True, but somebody may only want the Iterator interface to be
implemented.
> > By having both we give the user the flexibility to choose.
>
> Agreed. Trying to 'package' defensively :) SingletonListIterator could
> become a static on SingletonIterator:
> SingletonIterator.asListIterator(Object) or some such. Mainly just trying
> to make Collections easier to grokk.
>
> > > Second question. What's ListIteratorWrapper useful for?
> > > It seems to just let us throw a normal Iterator into something
requiring
> > > ListIterator-ness, except then it'll go ahead and throw exceptions on
most
> > > methods. So is it just an iterator that can get the previous element?
> > Yep, it allows forwards and backwards movement through any iterator, not
> > just list iterators. And no, I don't know why its useful.
>
> So basically a decorator pattern, but not a stunningly useful one.
>
> > > Next. MultiMap has a remove(Object, Object) contract and therefore is
not
> > > a tag interface as the javadoc states.
> > Actually MultiMap is a poor interface that probably should be changed.
It is
> > a difficult decision as we are not supposed to change interfaces, but it
is
> > perhaps unlikely that there are too many implementations of this one.
See
> > bugzilla.
>
> Agreed. My preference would be to remove MultiMap, rename MultiHashMap to
> MultiMap and then rewrite it to decorate a passed in Map. But I've said
> this before and not found the time to get stuck in.
>
> > > The javadoc for a priority queue does not explain what a priority
> > > queue is.
> > Not sure if I remember either.
>
> Heh. And we wonder why users are confused :)
>
> > > FastXxx classes say that they are not cross-platform, but in no way
> > > discuss which platforms they are targetted at. This makes these
classes
> > > useless except to the authors.
> > IIRC, nobody can ever answer this question. It may be a theoretical
risk, or
> > a real one. Who knows?
>
> Dunno. Hopefully someone on the project has a clue?
>
> Hen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [collections] Questions....
Posted by Takuya Murata <ta...@manjiro.net>.
> Agreed. Trying to 'package' defensively :) SingletonListIterator could
> become a static on SingletonIterator:
> SingletonIterator.asListIterator(Object) or some such. Mainly just
> trying
> to make Collections easier to grokk.
I hate tricky solution. Compared with this, having two
SingletonIterator and SingletonListIterator does make more sense.
>>> Second question. What's ListIteratorWrapper useful for?
>>> It seems to just let us throw a normal Iterator into something
>>> requiring
>>> ListIterator-ness, except then it'll go ahead and throw exceptions
>>> on most
>>> methods. So is it just an iterator that can get the previous element?
>> Yep, it allows forwards and backwards movement through any iterator,
>> not
>> just list iterators. And no, I don't know why its useful.
>
> So basically a decorator pattern, but not a stunningly useful one.
Again, this looks ugly too but I don't know better solution. Remember
adding things not only make things convenient but comes with cost of
maintenance, documentation and difficulty to comprehend.
Takuya Murata
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Questions....
Posted by Takuya Murata <ta...@manjiro.net>.
> Agreed. Trying to 'package' defensively :) SingletonListIterator could
> become a static on SingletonIterator:
> SingletonIterator.asListIterator(Object) or some such. Mainly just
> trying
> to make Collections easier to grokk.
I hate tricky solution. Compared with this, having two
SingletonIterator and SingletonListIterator does make more sense.
>>> Second question. What's ListIteratorWrapper useful for?
>>> It seems to just let us throw a normal Iterator into something
>>> requiring
>>> ListIterator-ness, except then it'll go ahead and throw exceptions
>>> on most
>>> methods. So is it just an iterator that can get the previous element?
>> Yep, it allows forwards and backwards movement through any iterator,
>> not
>> just list iterators. And no, I don't know why its useful.
>
> So basically a decorator pattern, but not a stunningly useful one.
Again, this looks ugly too but I don't know better solution. Remember
adding things not only make things convenient but comes with cost of
maintenance, documentation and difficulty to comprehend.
Takuya Murata
Re: [collections] Questions....
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 19 Aug 2003, Stephen Colebourne wrote:
> From: "Henri Yandell" <ba...@generationjava.com>
> > Firstly, SingletonIterator and SingletonListIterator seem quite similar.
> > Apart from the extra type of 'ListIterator', it appears that a
> > SingletonListIterator can do the job of a SingletonIterator in all jobs.
> > Could just remove SingleIterator.
> True, but somebody may only want the Iterator interface to be implemented.
> By having both we give the user the flexibility to choose.
Agreed. Trying to 'package' defensively :) SingletonListIterator could
become a static on SingletonIterator:
SingletonIterator.asListIterator(Object) or some such. Mainly just trying
to make Collections easier to grokk.
> > Second question. What's ListIteratorWrapper useful for?
> > It seems to just let us throw a normal Iterator into something requiring
> > ListIterator-ness, except then it'll go ahead and throw exceptions on most
> > methods. So is it just an iterator that can get the previous element?
> Yep, it allows forwards and backwards movement through any iterator, not
> just list iterators. And no, I don't know why its useful.
So basically a decorator pattern, but not a stunningly useful one.
> > Next. MultiMap has a remove(Object, Object) contract and therefore is not
> > a tag interface as the javadoc states.
> Actually MultiMap is a poor interface that probably should be changed. It is
> a difficult decision as we are not supposed to change interfaces, but it is
> perhaps unlikely that there are too many implementations of this one. See
> bugzilla.
Agreed. My preference would be to remove MultiMap, rename MultiHashMap to
MultiMap and then rewrite it to decorate a passed in Map. But I've said
this before and not found the time to get stuck in.
> > The javadoc for a priority queue does not explain what a priority
> > queue is.
> Not sure if I remember either.
Heh. And we wonder why users are confused :)
> > FastXxx classes say that they are not cross-platform, but in no way
> > discuss which platforms they are targetted at. This makes these classes
> > useless except to the authors.
> IIRC, nobody can ever answer this question. It may be a theoretical risk, or
> a real one. Who knows?
Dunno. Hopefully someone on the project has a clue?
Hen
Re: [collections] Questions....
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 19 Aug 2003, Stephen Colebourne wrote:
> From: "Henri Yandell" <ba...@generationjava.com>
> > Firstly, SingletonIterator and SingletonListIterator seem quite similar.
> > Apart from the extra type of 'ListIterator', it appears that a
> > SingletonListIterator can do the job of a SingletonIterator in all jobs.
> > Could just remove SingleIterator.
> True, but somebody may only want the Iterator interface to be implemented.
> By having both we give the user the flexibility to choose.
Agreed. Trying to 'package' defensively :) SingletonListIterator could
become a static on SingletonIterator:
SingletonIterator.asListIterator(Object) or some such. Mainly just trying
to make Collections easier to grokk.
> > Second question. What's ListIteratorWrapper useful for?
> > It seems to just let us throw a normal Iterator into something requiring
> > ListIterator-ness, except then it'll go ahead and throw exceptions on most
> > methods. So is it just an iterator that can get the previous element?
> Yep, it allows forwards and backwards movement through any iterator, not
> just list iterators. And no, I don't know why its useful.
So basically a decorator pattern, but not a stunningly useful one.
> > Next. MultiMap has a remove(Object, Object) contract and therefore is not
> > a tag interface as the javadoc states.
> Actually MultiMap is a poor interface that probably should be changed. It is
> a difficult decision as we are not supposed to change interfaces, but it is
> perhaps unlikely that there are too many implementations of this one. See
> bugzilla.
Agreed. My preference would be to remove MultiMap, rename MultiHashMap to
MultiMap and then rewrite it to decorate a passed in Map. But I've said
this before and not found the time to get stuck in.
> > The javadoc for a priority queue does not explain what a priority
> > queue is.
> Not sure if I remember either.
Heh. And we wonder why users are confused :)
> > FastXxx classes say that they are not cross-platform, but in no way
> > discuss which platforms they are targetted at. This makes these classes
> > useless except to the authors.
> IIRC, nobody can ever answer this question. It may be a theoretical risk, or
> a real one. Who knows?
Dunno. Hopefully someone on the project has a clue?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Questions....
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Henri Yandell" <ba...@generationjava.com>
> Firstly, SingletonIterator and SingletonListIterator seem quite similar.
> Apart from the extra type of 'ListIterator', it appears that a
> SingletonListIterator can do the job of a SingletonIterator in all jobs.
> Could just remove SingleIterator.
True, but somebody may only want the Iterator interface to be implemented.
By having both we give the user the flexibility to choose.
> Second question. What's ListIteratorWrapper useful for?
> It seems to just let us throw a normal Iterator into something requiring
> ListIterator-ness, except then it'll go ahead and throw exceptions on most
> methods. So is it just an iterator that can get the previous element?
Yep, it allows forwards and backwards movement through any iterator, not
just list iterators. And no, I don't know why its useful.
> Next. MultiMap has a remove(Object, Object) contract and therefore is not
> a tag interface as the javadoc states.
Actually MultiMap is a poor interface that probably should be changed. It is
a difficult decision as we are not supposed to change interfaces, but it is
perhaps unlikely that there are too many implementations of this one. See
bugzilla.
> The javadoc for a priority queue does not explain what a priority
> queue is.
Not sure if I remember either.
> FastXxx classes say that they are not cross-platform, but in no way
> discuss which platforms they are targetted at. This makes these classes
> useless except to the authors.
IIRC, nobody can ever answer this question. It may be a theoretical risk, or
a real one. Who knows?
Stephen
Re: [collections] Questions....
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Henri Yandell" <ba...@generationjava.com>
> Firstly, SingletonIterator and SingletonListIterator seem quite similar.
> Apart from the extra type of 'ListIterator', it appears that a
> SingletonListIterator can do the job of a SingletonIterator in all jobs.
> Could just remove SingleIterator.
True, but somebody may only want the Iterator interface to be implemented.
By having both we give the user the flexibility to choose.
> Second question. What's ListIteratorWrapper useful for?
> It seems to just let us throw a normal Iterator into something requiring
> ListIterator-ness, except then it'll go ahead and throw exceptions on most
> methods. So is it just an iterator that can get the previous element?
Yep, it allows forwards and backwards movement through any iterator, not
just list iterators. And no, I don't know why its useful.
> Next. MultiMap has a remove(Object, Object) contract and therefore is not
> a tag interface as the javadoc states.
Actually MultiMap is a poor interface that probably should be changed. It is
a difficult decision as we are not supposed to change interfaces, but it is
perhaps unlikely that there are too many implementations of this one. See
bugzilla.
> The javadoc for a priority queue does not explain what a priority
> queue is.
Not sure if I remember either.
> FastXxx classes say that they are not cross-platform, but in no way
> discuss which platforms they are targetted at. This makes these classes
> useless except to the authors.
IIRC, nobody can ever answer this question. It may be a theoretical risk, or
a real one. Who knows?
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Questions....
Posted by Rich Dougherty <ri...@rd.gen.nz>.
>So the question is do we really need SingletonIterator and such. If we
>want to eliminate the number of methods or classes, then what about one
>class for all of collections or iterators? I suppose the use of
>singleton methods and classes is almost always to provide an object
>matching a data type you want. Thus, we can have a class like
>
>class Singleton implements List, SortedSet, Bag, Iterator, ListIterator
>{
>}
>
>Although it is usually bad practice to aggregate several different
>functionalities into one class, in this case, it might be fine.
>
>Yes, this is in line with your proposal; we can use
>SingletonListIterator for both Iterator and ListIterator. I think the
>problem of this solution is users probably expect SingletonIterator
>intuitively and might be puzzled why there is no such.
I don't know if such a class makes sense... The next() method should
return its contents on the first call, but return null for all
successive calls. Thus it could only be used as an Iterator once, which
doesn't seem very useful to me.
Rich
--
Rich Dougherty
http://www.rd.gen.nz/
Re: [collections] Questions....
Posted by __matthewHawthorne <mh...@alumni.pitt.edu>.
I think that the elimination of _unnecessary_ methods and classes is a
noble goal.
For example, In the SingletonIterator vs. SingletonListIterator
situation, as long as the logic to implement the extra methods specified
by java.util.ListIterator does not cause significant performance
overhead, it seems reasonable to use SingletonListIterator as a standard
Iterator also. (I'm pretty sure that's what is being suggested.)
However, I don't agree with elimination just for elimination's sake,
which is how I interpret the suggestion of defining a single class which
implements List, SortedSet, Bag, Iterator, ListIterator, etc. I find it
simpler to allow each class to perform a single task, and perform it
well, then to force it to perform the job of 5 classes. I don't see the
benefit of such a solution. In my opinion, smaller, simpler classes are
easier to write, easier to maintain, easier to test, and easier to use.
Agreements/Disagreements?
On Tue, 2003-08-19 at 20:28, Takuya Murata wrote:
> Hi,
>
> So the question is do we really need SingletonIterator and such. If we
> want to eliminate the number of methods or classes, then what about one
> class for all of collections or iterators? I suppose the use of
> singleton methods and classes is almost always to provide an object
> matching a data type you want. Thus, we can have a class like
>
> class Singleton implements List, SortedSet, Bag, Iterator, ListIterator
> {
> }
>
> Although it is usually bad practice to aggregate several different
> functionalities into one class, in this case, it might be fine.
>
> Yes, this is in line with your proposal; we can use
> SingletonListIterator for both Iterator and ListIterator. I think the
> problem of this solution is users probably expect SingletonIterator
> intuitively and might be puzzled why there is no such.
>
> Takuya Murata
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [collections] Questions....
Posted by __matthewHawthorne <mh...@alumni.pitt.edu>.
I think that the elimination of _unnecessary_ methods and classes is a
noble goal.
For example, In the SingletonIterator vs. SingletonListIterator
situation, as long as the logic to implement the extra methods specified
by java.util.ListIterator does not cause significant performance
overhead, it seems reasonable to use SingletonListIterator as a standard
Iterator also. (I'm pretty sure that's what is being suggested.)
However, I don't agree with elimination just for elimination's sake,
which is how I interpret the suggestion of defining a single class which
implements List, SortedSet, Bag, Iterator, ListIterator, etc. I find it
simpler to allow each class to perform a single task, and perform it
well, then to force it to perform the job of 5 classes. I don't see the
benefit of such a solution. In my opinion, smaller, simpler classes are
easier to write, easier to maintain, easier to test, and easier to use.
Agreements/Disagreements?
On Tue, 2003-08-19 at 20:28, Takuya Murata wrote:
> Hi,
>
> So the question is do we really need SingletonIterator and such. If we
> want to eliminate the number of methods or classes, then what about one
> class for all of collections or iterators? I suppose the use of
> singleton methods and classes is almost always to provide an object
> matching a data type you want. Thus, we can have a class like
>
> class Singleton implements List, SortedSet, Bag, Iterator, ListIterator
> {
> }
>
> Although it is usually bad practice to aggregate several different
> functionalities into one class, in this case, it might be fine.
>
> Yes, this is in line with your proposal; we can use
> SingletonListIterator for both Iterator and ListIterator. I think the
> problem of this solution is users probably expect SingletonIterator
> intuitively and might be puzzled why there is no such.
>
> Takuya Murata
>
>
> ---------------------------------------------------------------------
> 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: [collections] Questions....
Posted by Takuya Murata <ta...@manjiro.net>.
On Wednesday, August 20, 2003, at 12:41 PM, Henri Yandell wrote:
>
>
> On Wed, 20 Aug 2003, Takuya Murata wrote:
>
>> Yes, this is in line with your proposal; we can use
>> SingletonListIterator for both Iterator and ListIterator. I think the
>> problem of this solution is users probably expect SingletonIterator
>> intuitively and might be puzzled why there is no such.
>
> Agreed. It is the logical name. So solution there is to remove
> SingletonListIterator and quietly make SingletonIterator a
> ListIterator? :)
>
> Hen
A tricky situation is
class A {
public void method (Iterator i);
public void method (ListIterator i);
};
new A ().method (new SingletonIterator ());
Otherwise, I think it is fine.
Re: [collections] Questions....
Posted by Takuya Murata <ta...@manjiro.net>.
On Wednesday, August 20, 2003, at 12:41 PM, Henri Yandell wrote:
>
>
> On Wed, 20 Aug 2003, Takuya Murata wrote:
>
>> Yes, this is in line with your proposal; we can use
>> SingletonListIterator for both Iterator and ListIterator. I think the
>> problem of this solution is users probably expect SingletonIterator
>> intuitively and might be puzzled why there is no such.
>
> Agreed. It is the logical name. So solution there is to remove
> SingletonListIterator and quietly make SingletonIterator a
> ListIterator? :)
>
> Hen
A tricky situation is
class A {
public void method (Iterator i);
public void method (ListIterator i);
};
new A ().method (new SingletonIterator ());
Otherwise, I think it is fine.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Questions....
Posted by Henri Yandell <ba...@generationjava.com>.
On Wed, 20 Aug 2003, Takuya Murata wrote:
> Yes, this is in line with your proposal; we can use
> SingletonListIterator for both Iterator and ListIterator. I think the
> problem of this solution is users probably expect SingletonIterator
> intuitively and might be puzzled why there is no such.
Agreed. It is the logical name. So solution there is to remove
SingletonListIterator and quietly make SingletonIterator a ListIterator? :)
Hen
Re: [collections] Questions....
Posted by Henri Yandell <ba...@generationjava.com>.
On Wed, 20 Aug 2003, Takuya Murata wrote:
> Yes, this is in line with your proposal; we can use
> SingletonListIterator for both Iterator and ListIterator. I think the
> problem of this solution is users probably expect SingletonIterator
> intuitively and might be puzzled why there is no such.
Agreed. It is the logical name. So solution there is to remove
SingletonListIterator and quietly make SingletonIterator a ListIterator? :)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Questions....
Posted by Takuya Murata <ta...@manjiro.net>.
Hi,
So the question is do we really need SingletonIterator and such. If we
want to eliminate the number of methods or classes, then what about one
class for all of collections or iterators? I suppose the use of
singleton methods and classes is almost always to provide an object
matching a data type you want. Thus, we can have a class like
class Singleton implements List, SortedSet, Bag, Iterator, ListIterator
{
}
Although it is usually bad practice to aggregate several different
functionalities into one class, in this case, it might be fine.
Yes, this is in line with your proposal; we can use
SingletonListIterator for both Iterator and ListIterator. I think the
problem of this solution is users probably expect SingletonIterator
intuitively and might be puzzled why there is no such.
Takuya Murata
Re: [collections] Questions....
Posted by Takuya Murata <ta...@manjiro.net>.
Hi,
So the question is do we really need SingletonIterator and such. If we
want to eliminate the number of methods or classes, then what about one
class for all of collections or iterators? I suppose the use of
singleton methods and classes is almost always to provide an object
matching a data type you want. Thus, we can have a class like
class Singleton implements List, SortedSet, Bag, Iterator, ListIterator
{
}
Although it is usually bad practice to aggregate several different
functionalities into one class, in this case, it might be fine.
Yes, this is in line with your proposal; we can use
SingletonListIterator for both Iterator and ListIterator. I think the
problem of this solution is users probably expect SingletonIterator
intuitively and might be puzzled why there is no such.
Takuya Murata
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Questions....
Posted by Henri Yandell <ba...@generationjava.com>.
While this is a good question, it's not the actual problem I'm trying to
point out. SingletonIterator or singletonIterator() is a redundant method
in 99% of its usage. Only if someone has if(instanceof ListIterator) {.. }
else if(instanceof Iterator) would it change the funcationality.
Using XxxUtils [which is what java.util.Collections effectively is in
Commons language] as factories is something we've considered moving
towards for a while.
The biggest problem is that you end up with large XxxUtils classes [or
XxxFactory, whatever] which are hard to understand and comprehend.
However, a widely spread API with lots of classes is also hard to
understand and comprehend. Maybe there's a magic ratio of classes to
methods? :)
Anyway, I'm always +1 to a good standard feel to the Collections.
Currently I'm trying to ensure I understand what every class in
Collections does and for some it is a bit hard to comprehend with the
current documentation.
Hen
On Wed, 20 Aug 2003, Takuya Murata wrote:
> Hello,
>
> > Firstly, SingletonIterator and SingletonListIterator seem quite
> > similar.
> > Apart from the extra type of 'ListIterator', it appears that a
> > SingletonListIterator can do the job of a SingletonIterator in all
> > jobs.
> > Could just remove SingleIterator.
>
> I was thinking can we eliminate those classes by methods returning
> interface? It is always a good practice to use interface rather than
> specifying concrete class. I mean just like singleton method of
> java.util.Collections
>
> Code should be like:
>
> class Collections2 {
> public ResetableIterator singletonIterator () { ... }
> public ResetableListIterator singletonIterator () { ... }
> }
>
> It is possible to use just one concrete class for both methods above.
>
> Given there is a few discussion of code review, I think every one is
> busy maintaining the existing code base.
>
> Takuya Murata
> takusi@manjiro.net
>
>
> ---------------------------------------------------------------------
> 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: [collections] Questions....
Posted by Henri Yandell <ba...@generationjava.com>.
While this is a good question, it's not the actual problem I'm trying to
point out. SingletonIterator or singletonIterator() is a redundant method
in 99% of its usage. Only if someone has if(instanceof ListIterator) {.. }
else if(instanceof Iterator) would it change the funcationality.
Using XxxUtils [which is what java.util.Collections effectively is in
Commons language] as factories is something we've considered moving
towards for a while.
The biggest problem is that you end up with large XxxUtils classes [or
XxxFactory, whatever] which are hard to understand and comprehend.
However, a widely spread API with lots of classes is also hard to
understand and comprehend. Maybe there's a magic ratio of classes to
methods? :)
Anyway, I'm always +1 to a good standard feel to the Collections.
Currently I'm trying to ensure I understand what every class in
Collections does and for some it is a bit hard to comprehend with the
current documentation.
Hen
On Wed, 20 Aug 2003, Takuya Murata wrote:
> Hello,
>
> > Firstly, SingletonIterator and SingletonListIterator seem quite
> > similar.
> > Apart from the extra type of 'ListIterator', it appears that a
> > SingletonListIterator can do the job of a SingletonIterator in all
> > jobs.
> > Could just remove SingleIterator.
>
> I was thinking can we eliminate those classes by methods returning
> interface? It is always a good practice to use interface rather than
> specifying concrete class. I mean just like singleton method of
> java.util.Collections
>
> Code should be like:
>
> class Collections2 {
> public ResetableIterator singletonIterator () { ... }
> public ResetableListIterator singletonIterator () { ... }
> }
>
> It is possible to use just one concrete class for both methods above.
>
> Given there is a few discussion of code review, I think every one is
> busy maintaining the existing code base.
>
> Takuya Murata
> takusi@manjiro.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [collections] Questions....
Posted by Takuya Murata <ta...@manjiro.net>.
Hello,
> Firstly, SingletonIterator and SingletonListIterator seem quite
> similar.
> Apart from the extra type of 'ListIterator', it appears that a
> SingletonListIterator can do the job of a SingletonIterator in all
> jobs.
> Could just remove SingleIterator.
I was thinking can we eliminate those classes by methods returning
interface? It is always a good practice to use interface rather than
specifying concrete class. I mean just like singleton method of
java.util.Collections
Code should be like:
class Collections2 {
public ResetableIterator singletonIterator () { ... }
public ResetableListIterator singletonIterator () { ... }
}
It is possible to use just one concrete class for both methods above.
Given there is a few discussion of code review, I think every one is
busy maintaining the existing code base.
Takuya Murata
takusi@manjiro.net
Re: [collections] Questions....
Posted by Takuya Murata <ta...@manjiro.net>.
Hello,
> Firstly, SingletonIterator and SingletonListIterator seem quite
> similar.
> Apart from the extra type of 'ListIterator', it appears that a
> SingletonListIterator can do the job of a SingletonIterator in all
> jobs.
> Could just remove SingleIterator.
I was thinking can we eliminate those classes by methods returning
interface? It is always a good practice to use interface rather than
specifying concrete class. I mean just like singleton method of
java.util.Collections
Code should be like:
class Collections2 {
public ResetableIterator singletonIterator () { ... }
public ResetableListIterator singletonIterator () { ... }
}
It is possible to use just one concrete class for both methods above.
Given there is a few discussion of code review, I think every one is
busy maintaining the existing code base.
Takuya Murata
takusi@manjiro.net
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org