[hibernate-dev] Returning Iterable

[Gunnar Morling]

Which case/change is this actually about?

I could swear we discussed that issue before a while ago and someone even
shared that very link.

Iterable IMO is good for things like result sets which you might not want
to have in memory all at once. Otherwise, I prefer returning Set/List which
makes the duplicate semantics apparent and are generally just more useful.
How do you know whether iterating really is the only thing users of a
method will do? It would help to know the case at hand.

It's a different thing for parameters of course. There I find Iterable good
if it is all I need as a method implementor: "Be conservative in what you
send, be liberal in what you accept".





2015-03-06 11:45 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> I heard it the first time, no need to draw guns :)
> I just added another viewpoint as I happened to also ponder Iterable vs
> dedicated API on another pull request.
>
>
> > On 6 mars 2015, at 11:01, Sanne Grinovero <sanne at hibernate.org> wrote:
> >
> > I was already aware of that blog, and while he makes some interesting
> > observations, I strongly disagree on it being a general rule. Like
> > many of the people commenting on the blog post, and the author himself
> > admits the title was too broad ;-)
> >
> > 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.
> > Exposing a List in this case was an error, as it's a leaky
> > abstraction: there is no ordering requirement, 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.
> >
> > We all know the rules of encapsulation: expose the least possible, but
> > no less... obviously the blog poster has a point in his case as he was
> > bitten by the "no less" problem.
> > I guess we all like encapsulation of classes, or we could as well move
> > back to public static fields rather than accessors. And you all return
> > "Set", and not "HashSet" right? Even though I often prefer to keep the
> > private field to use the type of the concrete collection, as
> > *privately* it may be useful (that's a case by case call).
> >
> > You expose the highest abstraction which satisfies the need, aiming at
> > a good balance of practicality for both the implementor of the
> > contract and the consumer.
> >
> > 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.
> > But then when the collections' whole point is to actually mutate,
> > you'd need to do such a wrap (or such a copy) on a per-invocation of
> > the read.. even if you don't agree on it being a good enough
> > performance reason, it adds on the readability of the code.
> > Often that's not a big deal, still why do I need to pay for any cost
> > if its reason to be is completely moot.
> >
> > Many of our internal contracts should be Iterable, especially if it's
> > only about iterating _some collection_.
> >
> > It's different of course if you expose it as a domain model to a user
> > API: in that case you don't really know what the use case's practical
> > needs are going to need, and then like the blog states being able to
> > run "size()" is often too compelling.
> >
> >
> >
> >> On 6 March 2015 at 08:12, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> >> We had that debate in one of the PR. We ended up not returning it for
> other reasons.
> >> A small additional stone to the discussion is here
> http://alexruiz.developerblogs.com/?p=2519
> >>
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>