You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by OCsite <oc...@ocs.cz> on 2025/02/06 09:20:01 UTC
a bug or my fault?
Hi there,
is this inconsistence intentional and the proper Groovy behaviour, or is that a bug and should I add a jira ticket?
Thanks!
===
groovy:000> a=[1,2]
===> [1, 2]
groovy:000> b=a as Object[]
===> [1, 2]
groovy:000> a[2]
===> null
groovy:000> b[2]
ERROR java.lang.ArrayIndexOutOfBoundsException:
Index 2 out of bounds for length 2
groovy:000>
===
Re: a bug or my fault?
Posted by Jochen Theodorou <bl...@gmx.org>.
Hi,
lists and arrays are different in Groovy. As already pointed out a array
is strictly limited by a certain length, while a List is not
necessarily. This behavior is quite old, from I think even before I
joined the project back in the pre Groovy 1.0 phase.
Groovy is actually using a mix from other languages for list. The
Javascript List for example allows accessing indexes beyond the maximum
length for writing and reading. The negative index usage on the other
hand comes from Python.
Javascript though has no List, they are Arrays and Python has no Arrays,
there are only lists... Groovy and Java have both, and we decided to
move away from the Java semantics in this. I never found a need to
change this actually.
Then String... well... the pov is that String is like an array of
char/codepoints and therefore does exhibit Groovy array behaviour.
But you all are right, that we really lack a more in depth description
of this.
bye Jochen
On 06.02.25 10:20, OCsite wrote:
> Hi there,
>
> is this inconsistence intentional and the proper Groovy behaviour, or is
> that a bug and should I add a jira ticket?
>
> Thanks!
>
> ===
>
> *groovy:*000*>* a=[1,2]
>
> *===>* [1, 2]
>
> *groovy:*000*>* b=a as Object[]
>
> *===>* [1, 2]
>
> *groovy:*000*>* a[2]
>
> *===>* null
>
> *groovy:*000*>* b[2]
>
> *ERROR*java.lang.ArrayIndexOutOfBoundsException:
>
> *Index 2 out of bounds for length 2*
>
> *groovy:*000*>*
>
> ===
Re: a bug or my fault?
Posted by "ocs@ocs.cz" <oc...@ocs.cz>.
Mauro,
> On 6. 2. 2025, at 18:24, Mauro Molinari <ma...@tiscali.it> wrote:
> Isn't the contract of List requiring to throw an IndexOutOfBoundsException though, in case index is invalid?
Far as the API contract goes, I guess it would be probably an undocumented behaviour (which actually makes sense, allowing each class to behave as it[s creator] wished), given
an index value (-self.size() <= idx < self.size()) <https://docs.groovy-lang.org/latest/html/groovy-jdk/java/lang/Iterable.html#getAt(int)>
neither Collection <https://docs.groovy-lang.org/latest/html/groovy-jdk/java/util/Collection.html#getAt(java.lang.String)> nor List <https://docs.groovy-lang.org/latest/html/groovy-jdk/java/util/List.html#getAt(int)> itself seem to add anything more of importance to that.
Note the Java documentation, well, for one, is not that relevant for Groovy ;), but far as you want to go with it, it knows neither getAt nor indices of course; and for get, its contract holds:
===
groovy:000> a=[1]
===> [1]
groovy:000> a[1]
===> null
groovy:000> a.getAt(1)
===> null
groovy:000> a.get(1)
ERROR java.lang.IndexOutOfBoundsException:
Index: 1, Size: 1
groovy:000>
===
In practice, List indices >= size always returned null and never threw far as I can recall.
All the best,
OC
> In data 6 Febbraio 2025 18:00:36 OCsite <oc...@ocs.cz> ha scritto:
>> Eric,
>>
>> I know of no oficial documentation explaining this (which does not mean there's none; perhaps I've just missed it).
>>
>> Some time ago Paul wrote unofficially that a list can be sort of seen as a map from indices to values, and as such, it is expected that non-existing indices return null instead of throwing.
>>
>> The question is whether the technical background (an array can be hardly considered a map, after all) or the polymorphic API (whatever it is, we want that indexing works consistently) should win. Myself I would vote for the latter, but alas I have no idea of the original intention (but for the quoted documentation line, which seems rather to support the latter too). That's why I've asked :)
>>
>> On the other hand, there's at least one more polymorphic indexing available, the one with strings; and in there non-existent indices throw too, quite consistently with arrays.
>>
>> Thanks and all the best,
>> OC
>>
>>> On 6. 2. 2025, at 17:27, Milles, Eric (TR Technology) via dev <de...@groovy.apache.org> wrote:
>>>
>>> Is there any explicit statement about how indexing beyond the end of a collection should work? Does it extend the collection or just return null. Does a withDefault collection do something different?
>>>
>>> In general, arrays and collections should work the same, so the statement in the working with arrays section is a good one. In the matter of indexing beyond the end of the array or collection, what is the shared behavior supposed to be:
>>>
>>> return default value for type — aka null for reference and 0/false for primitives
>>> throw out-of-bounds exception
>>> something else?
>>>
>>> From: OCsite <ocs@ocs.cz <ma...@ocs.cz>>
>>> Sent: Thursday, February 6, 2025 10:11 AM
>>> To: dev@groovy.apache.org <ma...@groovy.apache.org> <dev@groovy.apache.org <ma...@groovy.apache.org>>
>>> Subject: [EXT] Re: a bug or my fault?
>>>
>>> External Email: Use caution with links and attachments.
>>>
>>> The overall intention is that whether you are using an array or a collection, the code for working with the aggregate remains the same <https://urldefense.com/v3/__https://docs.groovy-lang.org/latest/html/documentation/*_working_with_arrays__;Iw!!GFN0sa3rsbfR8OLyAw!ezrONlzs3yG6lC6cFTDF2ASi61brEmoT2ix7QriL2Tg7vhHIhMXTwpPoYFbS77qNBafdycrQlnIZgRDxsA$>.
>>>
>>> In this particular case alas that good and noble intention does not quite work, and I wonder whether that is intentional (forgive the pun) or a mistake to be fixed in future, when there's nothing more pressing to do.
>>>
>>> On 6. 2. 2025, at 13:30, Søren Berg Glasius <soeren@glasius.dk <ma...@glasius.dk>> wrote:
>>>
>>> You assign 'b' as an Array, and arrays works differently than lists. Arrays are bound to their length, so 'a[2]' should report out of bounds as it is not 3 elements long, whereas a list b[2] would report null
>>>
>>> IMO it's working as intended.
>>>
>>> Den tors. 6. feb. 2025 kl. 10.20 skrev OCsite <ocs@ocs.cz <ma...@ocs.cz>>:
>>> Hi there,
>>>
>>> is this inconsistence intentional and the proper Groovy behaviour, or is that a bug and should I add a jira ticket?
>>>
>>> Thanks!
>>>
>>> ===
>>> groovy:000> a=[1,2]
>>> ===> [1, 2]
>>> groovy:000> b=a as Object[]
>>> ===> [1, 2]
>>> groovy:000> a[2]
>>> ===> null
>>> groovy:000> b[2]
>>> ERROR java.lang.ArrayIndexOutOfBoundsException:
>>> Index 2 out of bounds for length 2
>>> groovy:000>
>>> ===
>>>
>>>
>>> --
>>>
>>> Med venlig hilsen,
>>> Søren Berg Glasius
>>>
>>> Hedevej 1, Gl. Rye, 8680 Ry
>>> Mobile: +45 40 44 91 88
>>> --- Press ESC once to quit - twice to save the changes.
>>
>
>
Re: a bug or my fault?
Posted by Mauro Molinari <ma...@tiscali.it>.
Isn't the contract of List requiring to throw an IndexOutOfBoundsException
though, in case index is invalid?
Mauro Molinari
mauromol@tiscali.it
In data 6 Febbraio 2025 18:00:36 OCsite <oc...@ocs.cz> ha scritto:
> Eric,
>
> I know of no oficial documentation explaining this (which does not mean
> there's none; perhaps I've just missed it).
>
> Some time ago Paul wrote unofficially that a list can be sort of seen as a
> map from indices to values, and as such, it is expected that non-existing
> indices return null instead of throwing.
>
> The question is whether the technical background (an array can be hardly
> considered a map, after all) or the polymorphic API (whatever it is, we
> want that indexing works consistently) should win. Myself I would vote for
> the latter, but alas I have no idea of the original intention (but for the
> quoted documentation line, which seems rather to support the latter too).
> That's why I've asked :)
>
> On the other hand, there's at least one more polymorphic indexing
> available, the one with strings; and in there non-existent indices throw
> too, quite consistently with arrays.
>
> Thanks and all the best,
> OC
>
>
>> On 6. 2. 2025, at 17:27, Milles, Eric (TR Technology) via dev
>> <de...@groovy.apache.org> wrote:
>>
>>
>> Is there any explicit statement about how indexing beyond the end of a
>> collection should work? Does it extend the collection or just return null.
>> Does a withDefault collection do something different?
>>
>> In general, arrays and collections should work the same, so the statement
>> in the working with arrays section is a good one. In the matter of
>> indexing beyond the end of the array or collection, what is the shared
>> behavior supposed to be:
>>
>> return default value for type — aka null for reference and 0/false for
>> primitives
>> throw out-of-bounds exception
>> something else?
>>
>> From: OCsite <oc...@ocs.cz>
>> Sent: Thursday, February 6, 2025 10:11 AM
>> To: dev@groovy.apache.org <de...@groovy.apache.org>
>> Subject: [EXT] Re: a bug or my fault?
>>
>> External Email: Use caution with links and attachments.
>>
>> The overall intention is that whether you are using an array or a
>> collection, the code for working with the aggregate remains the same.
>>
>> In this particular case alas that good and noble intention does not quite
>> work, and I wonder whether that is intentional (forgive the pun) or a
>> mistake to be fixed in future, when there's nothing more pressing to do.
>>
>> On 6. 2. 2025, at 13:30, Søren Berg Glasius <so...@glasius.dk> wrote:
>>
>>
>> You assign 'b' as an Array, and arrays works differently than lists. Arrays
>> are bound to their length, so 'a[2]' should report out of bounds as it is
>> not 3 elements long, whereas a list b[2] would report null
>>
>>
>> IMO it's working as intended.
>>
>>
>> Den tors. 6. feb. 2025 kl. 10.20 skrev OCsite <oc...@ocs.cz>:
>> Hi there,
>>
>>
>> is this inconsistence intentional and the proper Groovy behaviour, or is
>> that a bug and should I add a jira ticket?
>>
>>
>> Thanks!
>>
>>
>> ===
>> groovy:000> a=[1,2]
>> ===> [1, 2]
>> groovy:000> b=a as Object[]
>> ===> [1, 2]
>> groovy:000> a[2]
>> ===> null
>> groovy:000> b[2]
>> ERROR java.lang.ArrayIndexOutOfBoundsException:
>> Index 2 out of bounds for length 2
>> groovy:000>
>> ===
>>
>>
>>
>>
>> --
>>
>>
>> Med venlig hilsen,
>> Søren Berg Glasius
>>
>> Hedevej 1, Gl. Rye, 8680 Ry
>> Mobile: +45 40 44 91 88
>> --- Press ESC once to quit - twice to save the changes.
Re: a bug or my fault?
Posted by OCsite <oc...@ocs.cz>.
Eric,
I know of no oficial documentation explaining this (which does not mean there's none; perhaps I've just missed it).
Some time ago Paul wrote unofficially that a list can be sort of seen as a map from indices to values, and as such, it is expected that non-existing indices return null instead of throwing.
The question is whether the technical background (an array can be hardly considered a map, after all) or the polymorphic API (whatever it is, we want that indexing works consistently) should win. Myself I would vote for the latter, but alas I have no idea of the original intention (but for the quoted documentation line, which seems rather to support the latter too). That's why I've asked :)
On the other hand, there's at least one more polymorphic indexing available, the one with strings; and in there non-existent indices throw too, quite consistently with arrays.
Thanks and all the best,
OC
> On 6. 2. 2025, at 17:27, Milles, Eric (TR Technology) via dev <de...@groovy.apache.org> wrote:
>
> Is there any explicit statement about how indexing beyond the end of a collection should work? Does it extend the collection or just return null. Does a withDefault collection do something different?
>
> In general, arrays and collections should work the same, so the statement in the working with arrays section is a good one. In the matter of indexing beyond the end of the array or collection, what is the shared behavior supposed to be:
>
> return default value for type — aka null for reference and 0/false for primitives
> throw out-of-bounds exception
> something else?
>
> From: OCsite <ocs@ocs.cz <ma...@ocs.cz>>
> Sent: Thursday, February 6, 2025 10:11 AM
> To: dev@groovy.apache.org <ma...@groovy.apache.org> <dev@groovy.apache.org <ma...@groovy.apache.org>>
> Subject: [EXT] Re: a bug or my fault?
>
> External Email: Use caution with links and attachments.
>
> The overall intention is that whether you are using an array or a collection, the code for working with the aggregate remains the same <https://urldefense.com/v3/__https://docs.groovy-lang.org/latest/html/documentation/*_working_with_arrays__;Iw!!GFN0sa3rsbfR8OLyAw!ezrONlzs3yG6lC6cFTDF2ASi61brEmoT2ix7QriL2Tg7vhHIhMXTwpPoYFbS77qNBafdycrQlnIZgRDxsA$>.
>
> In this particular case alas that good and noble intention does not quite work, and I wonder whether that is intentional (forgive the pun) or a mistake to be fixed in future, when there's nothing more pressing to do.
>
> On 6. 2. 2025, at 13:30, Søren Berg Glasius <soeren@glasius.dk <ma...@glasius.dk>> wrote:
>
> You assign 'b' as an Array, and arrays works differently than lists. Arrays are bound to their length, so 'a[2]' should report out of bounds as it is not 3 elements long, whereas a list b[2] would report null
>
> IMO it's working as intended.
>
> Den tors. 6. feb. 2025 kl. 10.20 skrev OCsite <ocs@ocs.cz <ma...@ocs.cz>>:
> Hi there,
>
> is this inconsistence intentional and the proper Groovy behaviour, or is that a bug and should I add a jira ticket?
>
> Thanks!
>
> ===
> groovy:000> a=[1,2]
> ===> [1, 2]
> groovy:000> b=a as Object[]
> ===> [1, 2]
> groovy:000> a[2]
> ===> null
> groovy:000> b[2]
> ERROR java.lang.ArrayIndexOutOfBoundsException:
> Index 2 out of bounds for length 2
> groovy:000>
> ===
>
>
> --
>
> Med venlig hilsen,
> Søren Berg Glasius
>
> Hedevej 1, Gl. Rye, 8680 Ry
> Mobile: +45 40 44 91 88
> --- Press ESC once to quit - twice to save the changes.
Re: a bug or my fault?
Posted by MG <mg...@arscreat.com>.
Hi OC,
1. I would be totally onboard with having a switch to turn off all the
Groovy features that might have made sense in the early days when
thinking of it as a script language, but which in my eyes you do not
want/need when using it as a full blown programming language.
2. However:
1. Given my past experience with suggestion of (much smaller/more
harmless) changes by different people here, I highly doubt a
concensus on that could ever be reached.
2. But even before that: The added effort of
implementing/maintaining this is, as you said, most likely
prohibitive.
Cheers,
mg
On 06/02/2025 21:18, ocs@ocs.cz wrote:
> MG,
>
>> On 6. 2. 2025, at 21:05, MG <mg...@arscreat.com> wrote:
>> I was talking about an ideal world, as a starting point on how things
>> imho should behave (and why), as the point towards which one should
>> try to move as far as constraints such as backward compatibility allows.
>
> In /ideal/ world there should be compiler
> options/configurations/pragmas for all such debatable things, with a
> well-known and easily accessible setups for backward compatibility in
> case of breaking improvements, allowing each programmer to personally
> decide which (and for which particular /sub-/project) to embrace and
> which not.
>
> Of course it would be sort of lots of extra work for the guys who do
> the hard work on the compiler; and probably it would make it slower,
> too. TANSTAAFL.
>
> Thanks and all the best,
> OC
>
Re: a bug or my fault?
Posted by "ocs@ocs.cz" <oc...@ocs.cz>.
MG,
> On 6. 2. 2025, at 21:05, MG <mg...@arscreat.com> wrote:
> I was talking about an ideal world, as a starting point on how things imho should behave (and why), as the point towards which one should try to move as far as constraints such as backward compatibility allows.
In ideal world there should be compiler options/configurations/pragmas for all such debatable things, with a well-known and easily accessible setups for backward compatibility in case of breaking improvements, allowing each programmer to personally decide which (and for which particular /sub-/project) to embrace and which not.
Of course it would be sort of lots of extra work for the guys who do the hard work on the compiler; and probably it would make it slower, too. TANSTAAFL.
Thanks and all the best,
OC
Re: a bug or my fault?
Posted by MG <mg...@arscreat.com>.
On 06/02/2025 20:37, ocs@ocs.cz wrote:
> Well but again, making List throw in future would break a vast
> codebase, which is a big no-no.
I was talking about an ideal world, as a starting point on how things
imho should behave (and why), as the point towards which one should try
to move as far as constraints such as backward compatibility allows.
> Far as I know, there's no auto-extending unless you explicitly ask for
> that by withDefault.
I was replying to Eric asking "Is there any explicit statement about how
indexing beyond the end of a collection should work? /Does it extend the
collection/ or just return null."
Cheers,
mg
Re: a bug or my fault?
Posted by MG <mg...@arscreat.com>.
On 06/02/2025 20:48, ocs@ocs.cz wrote:
> P.S. Besides, a decent implementation of size-extend in case of too
> big gaps should automatically switch the underlying implementation to
> a sparse list, of which the programmer does not need to be expliticly
> aware :)
This would e.g. mean that index access would no longer be constant time
for this collection going forward, so I would 100% not want for this to
happen automatically.
> P.P.S. I've tried array.withDefault and found it is not supported, and
> one is forced to uglies like “(arr as List).withDefault...”. That's
> one thing I would add; could hardly break any current code I'd say?
I agree that array support in Groovy could in principle use some love: I
e.g. tried to use arrays in cases where the number of elements would
always remain constant years back in our framework, but then eventually
just switched to using immutable Groovy array lists instead, since it
was so much more convenient.
Cheers,
mg
Re: a bug or my fault?
Posted by "ocs@ocs.cz" <oc...@ocs.cz>.
P.S. Besides, a decent implementation of size-extend in case of too big gaps should automatically switch the underlying implementation to a sparse list, of which the programmer does not need to be expliticly aware :)
P.P.S. I've tried array.withDefault and found it is not supported, and one is forced to uglies like “(arr as List).withDefault...”. That's one thing I would add; could hardly break any current code I'd say? Or do I overlook something of importance?
> On 6. 2. 2025, at 20:37, ocs@ocs.cz wrote:
>
> Well but again, making List throw in future would break a vast codebase, which is a big no-no.
>
> Far as I know, there's no auto-extending unless you explicitly ask for that by withDefault.
>
> Thanks and all the best,
> OC
>
>> On 6. 2. 2025, at 20:16, MG <mgbiz@arscreat.com <ma...@arscreat.com>> wrote:
>>
>> My take on this for list-like structures:
>> Since the potential for hard to track errors is so high - and for least surprise - default behavior should always be to throw on out-of-bounds access.
>> Returning a default value for out of bound access can be very conventient, but should be made explicit; we e.g. use the following naming convention in our code in this case:
>> getWithDefault(index, defaultVal)
>> We don't need that, but a more general version might be: getWithDefault(index, defaultValClosure)
>> getWithNullDefault(index)
>> Automatically extending the size seems to be the worst option, given that one too large index access could easily exhaust a computer's main memory (-:
>> Cheers,
>> mg
>>
>> On 06/02/2025 17:27, Milles, Eric (TR Technology) via dev wrote:
>>> Is there any explicit statement about how indexing beyond the end of a collection should work? Does it extend the collection or just return null. Does a withDefault collection do something different?
>>>
>>> In general, arrays and collections should work the same, so the statement in the working with arrays section is a good one. In the matter of indexing beyond the end of the array or collection, what is the shared behavior supposed to be:
>>>
>>> return default value for type — aka null for reference and 0/false for primitives
>>> throw out-of-bounds exception
>>> something else?
>>>
>>> From: OCsite <oc...@ocs.cz> <ma...@ocs.cz>
>>> Sent: Thursday, February 6, 2025 10:11 AM
>>> To: dev@groovy.apache.org <ma...@groovy.apache.org> <de...@groovy.apache.org> <ma...@groovy.apache.org>
>>> Subject: [EXT] Re: a bug or my fault?
>>>
>>> External Email: Use caution with links and attachments.
>>>
>>> The overall intention is that whether you are using an array or a collection, the code for working with the aggregate remains the same <https://urldefense.com/v3/__https://docs.groovy-lang.org/latest/html/documentation/*_working_with_arrays__;Iw!!GFN0sa3rsbfR8OLyAw!ezrONlzs3yG6lC6cFTDF2ASi61brEmoT2ix7QriL2Tg7vhHIhMXTwpPoYFbS77qNBafdycrQlnIZgRDxsA$>.
>>>
>>> In this particular case alas that good and noble intention does not quite work, and I wonder whether that is intentional (forgive the pun) or a mistake to be fixed in future, when there's nothing more pressing to do.
>>>
>>> On 6. 2. 2025, at 13:30, Søren Berg Glasius <so...@glasius.dk> <ma...@glasius.dk> wrote:
>>>
>>> You assign 'b' as an Array, and arrays works differently than lists. Arrays are bound to their length, so 'a[2]' should report out of bounds as it is not 3 elements long, whereas a list b[2] would report null
>>>
>>> IMO it's working as intended.
>>>
>>> Den tors. 6. feb. 2025 kl. 10.20 skrev OCsite <ocs@ocs.cz <ma...@ocs.cz>>:
>>> Hi there,
>>>
>>> is this inconsistence intentional and the proper Groovy behaviour, or is that a bug and should I add a jira ticket?
>>>
>>> Thanks!
>>>
>>> ===
>>> groovy:000> a=[1,2]
>>> ===> [1, 2]
>>> groovy:000> b=a as Object[]
>>> ===> [1, 2]
>>> groovy:000> a[2]
>>> ===> null
>>> groovy:000> b[2]
>>> ERROR java.lang.ArrayIndexOutOfBoundsException:
>>> Index 2 out of bounds for length 2
>>> groovy:000>
>>> ===
>>>
>>>
>>> --
>>>
>>> Med venlig hilsen,
>>> Søren Berg Glasius
>>>
>>> Hedevej 1, Gl. Rye, 8680 Ry
>>> Mobile: +45 40 44 91 88
>>> --- Press ESC once to quit - twice to save the changes.
>>>
>>
>
Re: a bug or my fault?
Posted by Jochen Theodorou <bl...@gmx.org>.
On 06.02.25 20:37, ocs@ocs.cz wrote:
[...]
> Far as I know, there's no auto-extending unless you explicitly ask for
> that by withDefault.
there is this:
> def l = [1,2]
> l[3] = 4
> assert l == [1,2,null,4]
As you see it autoextended the list from 2 elements to 4. Reading does
not extend unless you use the with default construct:
> def sample = [1,2,3].withDefault { index ->
> index % 2
> }
>
> assert sample[3] == 1
> assert sample[4] == 0
bye Jochen
Re: a bug or my fault?
Posted by "ocs@ocs.cz" <oc...@ocs.cz>.
Well but again, making List throw in future would break a vast codebase, which is a big no-no.
Far as I know, there's no auto-extending unless you explicitly ask for that by withDefault.
Thanks and all the best,
OC
> On 6. 2. 2025, at 20:16, MG <mg...@arscreat.com> wrote:
>
> My take on this for list-like structures:
> Since the potential for hard to track errors is so high - and for least surprise - default behavior should always be to throw on out-of-bounds access.
> Returning a default value for out of bound access can be very conventient, but should be made explicit; we e.g. use the following naming convention in our code in this case:
> getWithDefault(index, defaultVal)
> We don't need that, but a more general version might be: getWithDefault(index, defaultValClosure)
> getWithNullDefault(index)
> Automatically extending the size seems to be the worst option, given that one too large index access could easily exhaust a computer's main memory (-:
> Cheers,
> mg
>
> On 06/02/2025 17:27, Milles, Eric (TR Technology) via dev wrote:
>> Is there any explicit statement about how indexing beyond the end of a collection should work? Does it extend the collection or just return null. Does a withDefault collection do something different?
>>
>> In general, arrays and collections should work the same, so the statement in the working with arrays section is a good one. In the matter of indexing beyond the end of the array or collection, what is the shared behavior supposed to be:
>>
>> return default value for type — aka null for reference and 0/false for primitives
>> throw out-of-bounds exception
>> something else?
>>
>> From: OCsite <oc...@ocs.cz> <ma...@ocs.cz>
>> Sent: Thursday, February 6, 2025 10:11 AM
>> To: dev@groovy.apache.org <ma...@groovy.apache.org> <de...@groovy.apache.org> <ma...@groovy.apache.org>
>> Subject: [EXT] Re: a bug or my fault?
>>
>> External Email: Use caution with links and attachments.
>>
>> The overall intention is that whether you are using an array or a collection, the code for working with the aggregate remains the same <https://urldefense.com/v3/__https://docs.groovy-lang.org/latest/html/documentation/*_working_with_arrays__;Iw!!GFN0sa3rsbfR8OLyAw!ezrONlzs3yG6lC6cFTDF2ASi61brEmoT2ix7QriL2Tg7vhHIhMXTwpPoYFbS77qNBafdycrQlnIZgRDxsA$>.
>>
>> In this particular case alas that good and noble intention does not quite work, and I wonder whether that is intentional (forgive the pun) or a mistake to be fixed in future, when there's nothing more pressing to do.
>>
>> On 6. 2. 2025, at 13:30, Søren Berg Glasius <so...@glasius.dk> <ma...@glasius.dk> wrote:
>>
>> You assign 'b' as an Array, and arrays works differently than lists. Arrays are bound to their length, so 'a[2]' should report out of bounds as it is not 3 elements long, whereas a list b[2] would report null
>>
>> IMO it's working as intended.
>>
>> Den tors. 6. feb. 2025 kl. 10.20 skrev OCsite <ocs@ocs.cz <ma...@ocs.cz>>:
>> Hi there,
>>
>> is this inconsistence intentional and the proper Groovy behaviour, or is that a bug and should I add a jira ticket?
>>
>> Thanks!
>>
>> ===
>> groovy:000> a=[1,2]
>> ===> [1, 2]
>> groovy:000> b=a as Object[]
>> ===> [1, 2]
>> groovy:000> a[2]
>> ===> null
>> groovy:000> b[2]
>> ERROR java.lang.ArrayIndexOutOfBoundsException:
>> Index 2 out of bounds for length 2
>> groovy:000>
>> ===
>>
>>
>> --
>>
>> Med venlig hilsen,
>> Søren Berg Glasius
>>
>> Hedevej 1, Gl. Rye, 8680 Ry
>> Mobile: +45 40 44 91 88
>> --- Press ESC once to quit - twice to save the changes.
>>
>
Re: a bug or my fault?
Posted by MG <mg...@arscreat.com>.
My take on this for list-like structures:
1. Since the potential for hard to track errors is so high - and for
least surprise - default behavior should always be to throw on
out-of-bounds access.
2. Returning a default value for out of bound access can be very
conventient, but should be made explicit; we e.g. use the following
naming convention in our code in this case:
1. getWithDefault(index, defaultVal)
1. We don't need that, but a more general version might be:
getWithDefault(index, defaultValClosure)
2. getWithNullDefault(index)
3. Automatically extending the size seems to be the worst option, given
that one too large index access could easily exhaust a computer's
main memory (-:
Cheers,
mg
On 06/02/2025 17:27, Milles, Eric (TR Technology) via dev wrote:
> Is there any explicit statement about how indexing beyond the end of a
> collection should work? Does it extend the collection or just return
> null. Does a withDefault collection do something different?
>
> In general, arrays and collections should work the same, so the
> statement in the working with arrays section is a good one. In the
> matter of indexing beyond the end of the array or collection, what is
> the shared behavior supposed to be:
>
> 1.
> return default value for type — aka null for reference and 0/false
> for primitives
> 2.
> throw out-of-bounds exception
> 3.
> something else?
>
>
> ------------------------------------------------------------------------
> *From:* OCsite <oc...@ocs.cz>
> *Sent:* Thursday, February 6, 2025 10:11 AM
> *To:* dev@groovy.apache.org <de...@groovy.apache.org>
> *Subject:* [EXT] Re: a bug or my fault?
> *External Email:* Use caution with links and attachments.
>
>
> The overall intention is that whether you are using an array or a
> collection, the code for working with the aggregate remains the same
> <https://urldefense.com/v3/__https://docs.groovy-lang.org/latest/html/documentation/*_working_with_arrays__;Iw!!GFN0sa3rsbfR8OLyAw!ezrONlzs3yG6lC6cFTDF2ASi61brEmoT2ix7QriL2Tg7vhHIhMXTwpPoYFbS77qNBafdycrQlnIZgRDxsA$>.
>
>
> In this particular case alas that good and noble intention does not
> quite work, and I wonder whether that is intentional (forgive the pun)
> or a mistake to be fixed in future, when there's nothing more pressing
> to do.
>
> On 6. 2. 2025, at 13:30, Søren Berg Glasius <so...@glasius.dk> wrote:
>
> You assign 'b' as an Array, and arrays works differently than
> lists. Arrays are bound to their length, so 'a[2]' should report
> out of bounds as it is not 3 elements long, whereas a list b[2]
> would report null
>
> IMO it's working as intended.
>
> Den tors. 6. feb. 2025 kl. 10.20 skrev OCsite <ocs@ocs.cz
> <ma...@ocs.cz>>:
>
> Hi there,
>
> is this inconsistence intentional and the proper Groovy
> behaviour, or is that a bug and should I add a jira ticket?
>
> Thanks!
>
> ===
> *groovy:*000*>* a=[1,2]
> *===>* [1, 2]
> *groovy:*000*>* b=a as Object[]
> *===>* [1, 2]
> *groovy:*000*>* a[2]
> *===>* null
> *groovy:*000*>* b[2]
> *ERROR* java.lang.ArrayIndexOutOfBoundsException:
> *Index 2 out of bounds for length 2*
> *groovy:*000*>*
> ===
>
>
>
> --
>
> Med venlig hilsen,
> Søren Berg Glasius
>
> Hedevej 1, Gl. Rye, 8680 Ry
> Mobile: +45 40 44 91 88
> --- Press ESC once to quit - twice to save the changes.
>
>
Re: a bug or my fault?
Posted by "Milles, Eric (TR Technology) via dev" <de...@groovy.apache.org>.
Is there any explicit statement about how indexing beyond the end of a collection should work? Does it extend the collection or just return null. Does a withDefault collection do something different?
In general, arrays and collections should work the same, so the statement in the working with arrays section is a good one. In the matter of indexing beyond the end of the array or collection, what is the shared behavior supposed to be:
1.
return default value for type — aka null for reference and 0/false for primitives
2.
throw out-of-bounds exception
3.
something else?
________________________________
From: OCsite <oc...@ocs.cz>
Sent: Thursday, February 6, 2025 10:11 AM
To: dev@groovy.apache.org <de...@groovy.apache.org>
Subject: [EXT] Re: a bug or my fault?
External Email: Use caution with links and attachments.
The overall intention is that whether you are using an array or a collection, the code for working with the aggregate remains the same<https://urldefense.com/v3/__https://docs.groovy-lang.org/latest/html/documentation/*_working_with_arrays__;Iw!!GFN0sa3rsbfR8OLyAw!ezrONlzs3yG6lC6cFTDF2ASi61brEmoT2ix7QriL2Tg7vhHIhMXTwpPoYFbS77qNBafdycrQlnIZgRDxsA$>.
In this particular case alas that good and noble intention does not quite work, and I wonder whether that is intentional (forgive the pun) or a mistake to be fixed in future, when there's nothing more pressing to do.
On 6. 2. 2025, at 13:30, Søren Berg Glasius <so...@glasius.dk> wrote:
You assign 'b' as an Array, and arrays works differently than lists. Arrays are bound to their length, so 'a[2]' should report out of bounds as it is not 3 elements long, whereas a list b[2] would report null
IMO it's working as intended.
Den tors. 6. feb. 2025 kl. 10.20 skrev OCsite <oc...@ocs.cz>>:
Hi there,
is this inconsistence intentional and the proper Groovy behaviour, or is that a bug and should I add a jira ticket?
Thanks!
===
groovy:000> a=[1,2]
===> [1, 2]
groovy:000> b=a as Object[]
===> [1, 2]
groovy:000> a[2]
===> null
groovy:000> b[2]
ERROR java.lang.ArrayIndexOutOfBoundsException:
Index 2 out of bounds for length 2
groovy:000>
===
--
Med venlig hilsen,
Søren Berg Glasius
Hedevej 1, Gl. Rye, 8680 Ry
Mobile: +45 40 44 91 88
--- Press ESC once to quit - twice to save the changes.
Re: a bug or my fault?
Posted by OCsite <oc...@ocs.cz>.
The overall intention is that whether you are using an array or a collection, the code for working with the aggregate remains the same <https://docs.groovy-lang.org/latest/html/documentation/#_working_with_arrays>.
In this particular case alas that good and noble intention does not quite work, and I wonder whether that is intentional (forgive the pun) or a mistake to be fixed in future, when there's nothing more pressing to do.
> On 6. 2. 2025, at 13:30, Søren Berg Glasius <so...@glasius.dk> wrote:
>
> You assign 'b' as an Array, and arrays works differently than lists. Arrays are bound to their length, so 'a[2]' should report out of bounds as it is not 3 elements long, whereas a list b[2] would report null
>
> IMO it's working as intended.
>
> Den tors. 6. feb. 2025 kl. 10.20 skrev OCsite <ocs@ocs.cz <ma...@ocs.cz>>:
>> Hi there,
>>
>> is this inconsistence intentional and the proper Groovy behaviour, or is that a bug and should I add a jira ticket?
>>
>> Thanks!
>>
>> ===
>> groovy:000> a=[1,2]
>> ===> [1, 2]
>> groovy:000> b=a as Object[]
>> ===> [1, 2]
>> groovy:000> a[2]
>> ===> null
>> groovy:000> b[2]
>> ERROR java.lang.ArrayIndexOutOfBoundsException:
>> Index 2 out of bounds for length 2
>> groovy:000>
>> ===
>
>
>
> --
>
> Med venlig hilsen,
> Søren Berg Glasius
>
> Hedevej 1, Gl. Rye, 8680 Ry
> Mobile: +45 40 44 91 88
> --- Press ESC once to quit - twice to save the changes.
Re: a bug or my fault?
Posted by Søren Berg Glasius <so...@glasius.dk>.
You assign 'b' as an Array, and arrays works differently than lists. Arrays
are bound to their length, so 'a[2]' should report out of bounds as it is
not 3 elements long, whereas a list b[2] would report null
IMO it's working as intended.
Den tors. 6. feb. 2025 kl. 10.20 skrev OCsite <oc...@ocs.cz>:
> Hi there,
>
> is this inconsistence intentional and the proper Groovy behaviour, or is
> that a bug and should I add a jira ticket?
>
> Thanks!
>
> ===
>
> *groovy:*000*>* a=[1,2]
>
> *===>* [1, 2]
>
> *groovy:*000*>* b=a as Object[]
>
> *===>* [1, 2]
>
> *groovy:*000*>* a[2]
>
> *===>* null
>
> *groovy:*000*>* b[2]
>
> *ERROR* java.lang.ArrayIndexOutOfBoundsException:
>
> *Index 2 out of bounds for length 2*
>
> *groovy:*000*>*
> ===
>
--
Med venlig hilsen,
Søren Berg Glasius
Hedevej 1, Gl. Rye, 8680 Ry
Mobile: +45 40 44 91 88
--- Press ESC once to quit - twice to save the changes.