3:12 a.m.
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
5:01 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:36 a.m.
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
5:45 a.m.
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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
6:05 a.m.
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(a)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(a)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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3336
days inactive
3336
days old
4 comments
4 participants
participants (4)
-
Emmanuel Bernard -
Gunnar Morling -
Hardy Ferentschik -
Sanne Grinovero