commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hope, Matthew" <>
Subject RE: [collections] Questions....
Date Wed, 20 Aug 2003 12:18:22 GMT
> -----Original Message-----
> From: Takuya Murata [] 
> Sent: 20 August 2003 12:14
> To: Jakarta Commons Developers List
> Subject: Re: [collections] Questions....
> class Singleton implements List {
> }
> ResetableIterator i = new Singleton ("hello, world").iterator ();
> ListIterator li = new Singleton ("hello, world").listIterator ();
> ListIterator li = new Singleton ("hello, world").listIterator (10);

I personally have a problem with the use of the class name Singleton.
Singleton is a well known pattern for only having one instance of an Object
in an environment, this class does not achive this. I would think a name
likeSingleEntryIterator/TrivialIterator/MonoIterator or some such would be a
better descriptive name.
> To me, this solution sounds good. There is no tricky choice whether 
> SingletonIterator or SingletonListIterator. And we can avoid a big 
> xxxUtil classes instead of small objects and classes, resembling 
> traditional imperative languages such as C.

The whole point of Iterator is that it is collection type independent - no
matter what data structure in place iterator should supply you with every
Object in it - ordering appropriately if required.

If it is being used for code expecting a ListIterator I would say that that
code needs to be made more agnostic of the underlying implementation (given
that you would be using this quick method of supplying just the one value).
Though in fairness making it return a ListItertor (but keep the signature to
Iterator) would be no big deal.

> I am not sure if it is valid with the contract of interfaces to 
> implement both Set and List because ListIterator doesn't make sense 
> with listIterator but it doesn't look elegant to have two 
> SingletonList 
> and SingletonSet classes.

Perhaps it would be better to create a class SingleEntryCollection which
extends collection and implements the iterator method as well as the rest.
The cost is one additional object for your siple use case but it may provide
a clearer picture of what is being performed...If the Collection itself
implements Iterator then it can just return itself in response to the
method. I can't see a name clash except remove() and they are different
signatures in both return type and parameters...

If I'm missing the point of what you're trying to do here let me know

The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.

View raw message