commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Moore" <tmo...@blackboard.com>
Subject RE: [Collections][SUBMIT] TypedList
Date Tue, 23 Apr 2002 20:36:52 GMT
> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@eurobell.co.uk] 
> Sent: Tuesday, April 23, 2002 4:20 PM
> To: Jakarta Commons Developers List
> Subject: Re: [Collections][SUBMIT] TypedList
> 
> 
> From: Tim Moore <tmoore@blackboard.com>
> > > What is the point of the wrap method?
> > >
> > > Can I do:
> > >     List list = TypedList(new LinkedList());   ????
> >
> > Yes, but the syntax is
> > List list = TypedList.wrap(new LinkedList());
> 
> > I think the question is, why have the wrap method at all 
> > when all it 
> > does is call a private constructor with its arguments?  Why 
> > not just 
> > make the TypedList(List, Class) constructor public.
> 
> As I replied in another thread, TypedList(List, Class) does 
> something very different to TypedList(Class, Collection). I 
> left the Collection one as public because it respects best 
> the javadoc in the List class.

Well if you think of this as a list proxy with no backing store of its
own, then IMO it makes sense to think of the parameter as the collection
to delegate to instead of to copy items out of.  I feel like this is
still in keeping with the spirit of the Collection javadoc, which didn't
really consider collection proxies.

If you really want to copy the items from another Collection, you would
pass it to the constructor of the list that you're wrapping.

Though that does raise the question: if you wrap a list that has
preexisting elements that are invalid, how should that be handled (if at
all)?

> > Finally, to deal with the problem with the AbstractList iterator.  
> > Well, I don't see why this should subclass AbstractList at 
> > all instead 
> > of just delegating *all* of the List methods to the 
> > contained list.  
> > Then if there is a more efficient implementation provided, 
> > it will use 
> > that.
> 
> ListIterator/SubList has an add/set method. A straight 
> delegation would enable users to set unvalidated objects. But 
> a delegating iterator/sublist should solve this.

Exactly.

> 
> > Ultimately, I think what these suggestions amount to are List 
> > analogues to ProxyIterator and FilterIterator, and an 
> > implementation 
> > of Predicate that does type checking.  Then TypedList would 
> > just be a 
> > convenience for constructing a FilterList (PredicatedList? 
> > Whatever it 
> > ends up being
> > called...) with a TypePredicate (or whatever).  Though this 
> > almost begs
> > the question, why not just make it TypedCollection? ;-)
> 
> I would still want a List implementation, rather than just a 
> Collection.

How about both?! ;-)

> BTW, ProxyIterator make the wrapped iterator 
> available via get and set methods, so I can't use that

Oh yeah so it does :-\

Well I wonder if it's too late to change that.  If so, maybe we need an
OpaqueProxyIterator? Haha :-D
-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message