Hi, > First of, it's an SPI that we consume ourselves. We *know* that all we > need is to iterate, and the "for each" idiom is all we need.
How do you know that? At the moment that might be how it is implemented, but in the future this might change. In which case Iterable is a very unthankful data structure to work with. Also, in many cases some processing can be skipped if I do a simple empty/size check first. I cannot even do that with an Iterable. > Exposing a List in this case was an error, as it's a leaky > abstraction there is no ordering requirement, True, so maybe it should have not been a List, but rather a Set of Collection. Either of them is a better choice than Iterable. > and in fact I was > hoping to replace the implementation with a Set but I couldn't do that > as we committed to a contract which exposes a List. I am confused? If you are concerned about changing the API, why is the change to Iterable ok, but not to Set? > There also is a performance aspect. By returning List or Set, decency > rules require me to wrap them in their immutable counterparts, or make > defensive copies. Shall I come with the premature optimisation argument now? > Many of our internal contracts should be Iterable, especially if it's > only about iterating _some collection_. -1 --Hardy
pgpw_UBRBupJg.pgp
Description: PGP signature
_______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
