OK
I’d prefer e.g. to such as which feels all encompassing but that’s being picky.
On 20 Jun 2017, at 17:58, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
2017-06-19 14:58 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>
> On 16 Jun 2017, at 12:48, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>
>
>
> Back to the core subject, I can’t quite remember why I added Map to the list
> of isIterable() elements.
> I suppose that if we follow that path, any container that returns multiple
> elements should return isIterable == true (i.e. containers that call
> iterableValue, indexedValue or keyedValue.
> So I’d add arrays and any multi-valued container to the definition of
> isIterable()
>
>
> Ok, cool. I'll add arrays then.
>
> For other containers, I'd add this when adding more built-in
> containers to the spec in the future.
>
>
>
> My point is that isIterable goes beyond the built-in containers. It’s is
> true of custom containers (e.g. Guava’s etc). If we don’t change the
> JavaDoc, this is misleading.
Ok, it seems we need to mention the notion of custom supported
containers then. How about
@return {@code true} if the node represents an object contained in
a multi-valued container such as {@code Iterable} or {@code Map} or an
array, {@code false} otherwise
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev