Supporting arrays as well sounds reasonable to me. Unless there is any good argument against it. 2017-06-15 13:16 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: > > Hi all, > > On our road to the Proposed Final Draft (more on that in a separate > mail a bit), we've almost closed out all the relevant issues. > > One remaining issue is https://hibernate.atlassian.net/browse/BVAL-552 > which is about inconsistent behaviour of Node#isInIterable() when it > comes to arrays. The spec says this: > > "isInIterable() returns true if the node represents an object > contained in an Iterable or in a Map, false otherwise." > > Whereas the TCK has a test case which expects true to be returned for > arrays, too [1]. Naturally, that's how the RI (and any other > TCK-compliant implementation) implements this. > > Now my question is, should we simply change the spec and say > > "isInIterable() returns true if the node represents an object > contained in an Iterable, Map or an array, false otherwise." > > Given that maps are considered already, the method has to be about > "things that are iterable" and not java.lang.Iterable (which j.u.Map > doesn't extend). So considering arrays there seems consistent. > > Or do you, Emmanuel, remember a reason for the current specification > and it's actually a bug in the TCK? > > Thanks, > > --Gunnar > > [1] > https://github.com/beanvalidation/beanvalidation-tck/blob/master/tests/sr... > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

Should we include Stream as well?

Regards, Michael On 15 Jun 2017 14:55, "Matt Benson" <mbenson(a)apache.org&gt; wrote: > > +1 > > Matt > > On Thu, Jun 15, 2017 at 11:20 AM, Christian Kaltepoth > <christian(a)kaltepoth.de&gt; wrote: > > Supporting arrays as well sounds reasonable to me. Unless there is any > > good > > argument against it. > > > > 2017-06-15 13:16 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: > >> > >> Hi all, > >> > >> On our road to the Proposed Final Draft (more on that in a separate > >> mail a bit), we've almost closed out all the relevant issues. > >> > >> One remaining issue is https://hibernate.atlassian.net/browse/BVAL-552 > >> which is about inconsistent behaviour of Node#isInIterable() when it > >> comes to arrays. The spec says this: > >> > >> "isInIterable() returns true if the node represents an object > >> contained in an Iterable or in a Map, false otherwise." > >> > >> Whereas the TCK has a test case which expects true to be returned for > >> arrays, too [1]. Naturally, that's how the RI (and any other > >> TCK-compliant implementation) implements this. > >> > >> Now my question is, should we simply change the spec and say > >> > >> "isInIterable() returns true if the node represents an object > >> contained in an Iterable, Map or an array, false otherwise." > >> > >> Given that maps are considered already, the method has to be about > >> "things that are iterable" and not java.lang.Iterable (which j.u.Map > >> doesn't extend). So considering arrays there seems consistent. > >> > >> Or do you, Emmanuel, remember a reason for the current specification > >> and it's actually a bug in the TCK? > >> > >> Thanks, > >> > >> --Gunnar > >> > >> [1] > >> > >> https://github.com/beanvalidation/beanvalidation-tck/blob/master/tests/sr... > >> _______________________________________________ > >> beanvalidation-dev mailing list > >> beanvalidation-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > > > > > > > > -- > > Christian Kaltepoth > > Blog: http://blog.kaltepoth.de/ > > Twitter: http://twitter.com/chkal > > GitHub: https://github.com/chkal > > > > > > _______________________________________________ > > 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 _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

I looked at the spec and especially with the method inContainer Is the pattern supposed to always be inContainer(…).inIterable()? I suppose no because the spec did not have inContainer before.

So what does it mean, when inIterable() is used, then a inContainer call is implied?

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()

Emmanuel > On 15 Jun 2017, at 13:16, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > > Hi all, > > On our road to the Proposed Final Draft (more on that in a separate > mail a bit), we've almost closed out all the relevant issues. > > One remaining issue is https://hibernate.atlassian.net/browse/BVAL-552 > which is about inconsistent behaviour of Node#isInIterable() when it > comes to arrays. The spec says this: > > "isInIterable() returns true if the node represents an object > contained in an Iterable or in a Map, false otherwise." > > Whereas the TCK has a test case which expects true to be returned for > arrays, too [1]. Naturally, that's how the RI (and any other > TCK-compliant implementation) implements this. > > Now my question is, should we simply change the spec and say > > "isInIterable() returns true if the node represents an object > contained in an Iterable, Map or an array, false otherwise." > > Given that maps are considered already, the method has to be about > "things that are iterable" and not java.lang.Iterable (which j.u.Map > doesn't extend). So considering arrays there seems consistent. > > Or do you, Emmanuel, remember a reason for the current specification > and it's actually a bug in the TCK? > > Thanks, > > --Gunnar > > [1] https://github.com/beanvalidation/beanvalidation-tck/blob/master/tests/sr... > _______________________________________________ > 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

On 16 Jun 2017, at 12:48, Gunnar Morling <gunnar(a)hibernate.org&gt; 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.

_______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev