I'll reply on the user's list since that is where folks will most likely search for answers to this question.
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Mon, Mar 18, 2024 at 6:20 AM Simon Sadedin <ssade...@gmail.com> wrote: > > Sorry all - sent without a subject, so resending to correct that. > >> I sent this to groovy-users but didn't get much response. I am trying to >> understand some behaviour that is causing subtle and odd bugs in our code, >> which might be a bug or might be something I don't understand. >> >> The behaviour is that under very specific circumstances, Groovy is coercing >> a List of Maps to a single Map. A condensed example is >> >> class Foo { >> def foo(Map obj) { >> println(obj) >> } >> } >> z = [ >> [ a: 1, b:2] >> ] >> f = new Foo() >> f.foo(z) >> >> In here, even though the foo() method requires a Map, the call does not >> throw a type mismatch exception. Instead, the foo() method receives the Map >> object that is the first entry of the list as its argument. Consequently, it >> prints: >> >> [a:1, b:2] >> >> If instead, it is passed a list containing two Maps, eg: z = [ [ a: 1, b:2], >> [c:1, d:2] ], then it does throw a type conversion error. Also notable is >> that it will always throw the type conversion error if you attempt to coerce >> it outside the context of a function call, for example, using z.asType(Map). >> >> So it seems that under very specific circumstances that is both code context >> and data dependent, Groovy will perform a different type of type conversion >> to what it would do otherwise, but this is data dependent which is a bit >> unsatisfying. >> >> Can anyone explain why it does this and what the rationale is? Or is it >> actually a bug? > > > Cheers, > > Simon
