commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [IO] DirectoryWalker Collection parameter types
Date Fri, 08 Jan 2010 13:37:48 GMT
On 08/01/2010, sebb <sebbaz@gmail.com> wrote:
> On 08/01/2010, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>  > On Thu, Jan 7, 2010 at 9:51 PM, sebb <sebbaz@gmail.com> wrote:
>  >  > The overridable methods in DirectoryWalker currently use Collection<?>
>  >  > as a parameter type.
>  >  >
>  >  > As far as I can tell, the Collections need to contain File objects, so
>  >  > would it not be better to use Collection<File>?
>  >  >
>  >  > Might be nice to use Collection<? extends File>, but when I tried that
>  >  > there were some problems with the test cases.
>  >  >
>  >  > Any views?
>  >
>  >
>  > DirectoryWalker doesn't actually control what gets put into the
>  >  collection - the user can put whatever they want. So someone could,
>  >  for example, use it to add String file names to the collection. If we
>  >  lock it down to File then that would break for them.
>
>
> OK, I see. Perhaps the Javadoc should make this more explicit.
>
>  Also, there don't seem to be any unit tests apart from ones which use
>  File entries. I'll try to add some.
>

I'm having trouble removing the "raw type" warnings from the existing
test cases.
It's not clear how to write type-safe classes that override the
methods in DirectoryWalker.

The override only works if one uses Collection<?> or Collection<?
extends Object> as the results parameter type, but then results.add()
generates a compiler error, as one cannot add anything to a collection
of <?>.

One can solve the problem by casting results to the appropriate type,
but that will be an unchecked cast. Every implementation will need to
include the casts, and it does not make any use of the type-checking
features of generics.

The DirectoryWalker class probably needs to be genericised, so the
user can specify what Collection type to be used.

Alternatively, maybe the results parameter could be specified as
Collection<Object>.
However, that will require lots of casts in user code, and does not
make best use of generics either.

Any other solutions?

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

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


Mime
View raw message