lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Mularien <pmular...@deploy.com>
Subject Re: getAllFieldNames diffs
Date Wed, 13 Nov 2002 19:22:33 GMT
Actually, I started thinking about this as I was going to make the 
changes, I don't believe it is appropriate to return a Set after all. I 
think that the post condition assertion that we're making about the 
contents of the returned data (uniqueness) needn't be enforced by the 
return type itself, because at some point we might choose to drop or 
modify that constraint. At that point, we'd need to change the API and 
introduce incompatibility.

Since we're using a Set internally, as you mentioned, the uniqueness 
constraint is still enforced (internally), but externally, users need to 
take it on faith that the method is behaving according to the assertions 
made. I believe this is consistent with most other APIs that behave in a 
similar fashion with regards to post condition assertions.

So --- I think I'd propose that the diffs I made be applied "as-is", 
given that the other thread (Collections vs. Iterator vs. Enumeration) 
also seems to have wrapped up in favor of Collection being returned in 
"new" APIs.

Anyone disagree?

Thanks
Peter

Darren Hobbs wrote:

>Given that the concrete implementation returns a Set and the javadoc states
>that the field names will be unique, would it better to declare the method
>to return a Set rather than a Collection?  That would seem to better capture
>the intention.  Apologies if this seems nit-picky - it means I can't find
>anything worse wrong with it!
>
>Regards,
>
>-Darren
>
>
>--
>To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
>
>
>  
>


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


Mime
View raw message