commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@eurobell.co.uk>
Subject Re: [Collections][SUBMIT] TypedList
Date Tue, 23 Apr 2002 20:20:29 GMT
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.

> Not to be nit-picky, but I'd also personally suggest switching the order
> of parameters to be consistent with the other constructors.

Same as above really. If they were both public, and the constructor was
reversed, then people would forever be calling the wrong constructor.

> 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.

> 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.
BTW, ProxyIterator make the wrapped iterator available via get and set
methods, so I can't use that


> Overall, though, this is a great idea!  Thanks! :-)
Cheers
Stephen

--
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


> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@eurobell.co.uk]
> Sent: Tuesday, April 23, 2002 3:36 PM
> To: Jakarta Commons Developers List
> Subject: Re: [Collections][SUBMIT] TypedList
>
>
> From: Henri Yandell <bayard@generationjava.com>
> > Could we also have TypedMap and TypedSet?
>
> Don't see why not.
>
> > The way I did this was:
> >
> > TypedStructure interface. AbstractTypedStructure class.
> > IllegalTypeException exception.
> >
> > Then TypedSet/List/Map implement Set/List/Map and extend
> > AbstractTypedStructure.
>
> I'm not quite sure as to what benefits AbstractTypedStructure
> gives you. The implementation of TypedList makes use of the
> AbstractList class for its iterators and subList. Extending
> something else would cause problems...
>
> > 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());
> However, as noted above, the iterator is based on
> AbstractList - not much use for LinkedList. I'll see if I can
> fix this ;-)
>
> Stephen
>
> >
> > Hen
> >
> > On Tue, 23 Apr 2002, James Strachan wrote:
> >
> > > +1
> > >
> > > this seems a good idea.
> > >
> > > James
> > > ----- Original Message -----
> > > From: "Jack, Paul" <pjack@sfaf.org>
> > > To: "'Jakarta Commons Developers List'"
> > > <commons-dev@jakarta.apache.org>
> > > Sent: Tuesday, April 23, 2002 4:14 PM
> > > Subject: RE: [Collections][SUBMIT] TypedList
> > >
> > >
> > > > Hi Steve,
> > > >
> > > > Your TypedList got me thinking...At first I thought,
> wouldn't it
> > > > be nice to specify a parameter that would allow the
> null element
> > > > (sometimes I need a list that allows nulls)...then I got to
> > > > thinking, actually wouldn't it be nice if the validate() method
> > > > could be overridden by a subclass to allow more than one class
> > > > type...then I thought, actually, wouldn't it be nice if the
> > > > validation were completely generic, so that you supplied the
> > > > validation routine in the constructor of the list...then I
> > > > realized, the collections package already defines an
> interface for
> > > > validations (Predicate)...
> > > >
> > > > So...do you think it's a good idea to alter TypedList
> so that it
> > > > takes a Predicate in its constructor?  You could then supply a
> > > > concrete Predicate that does the Class.isInstance check...
> > > >
> > > > -Paul
> > > >
> > > > -----Original Message-----
> > > > From: Stephen Colebourne [mailto:scolebourne@eurobell.co.uk]
> > > > Sent: Sunday, April 21, 2002 2:13 PM
> > > > To: Jakarta Commons Developers List
> > > > Subject: [Collections][SUBMIT] TypedList
> > > >
> > > >
> > > > Hi,
> > > > After a quick check, I could find no implementation of a type
> > > > checking
> > > list
> > > > in collections. As I needed it, I have created one. Here is the
> > > > class
> > > > javadoc:
> > > >  * TypedList is a list wrapper that supports type checking. Only
> elements
> > > >  * of the specified type (or a subclass) can be added
> to the list.
> > > > An
> > > >  * attempt to add a different kind of object, or null,
> will cause an
> > > >  * <tt>IllegalArgumentException</tt>.
> > > >  * <p>
> > > >  * Constructing a new instance of this class will use
> an ArrayList
> behind
> > > >  * the scenes. Alternatively, the static <tt>wrap</tt>
> method can
> > > > be
> > > >  * used to wrap any object implementing List.
> > > >
> > > > The code is attached as a zip. Feedback welcome on
> whether this is
> > > suitable
> > > > for inclusion in the collections area.
> > > >
> > > > Stephen

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




--
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