Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.apache.org
MIME-Version: 1.0
In-Reply-To: <719a4011-837f-095d-b744-3e043111322d@gmx.org>
References: <CAPbPdOapNtVc0jK9oy7t_+vQOOf25Y7CgMdbCnB=-br3b6Fa7w@mail.gmail.com>
 <719a4011-837f-095d-b744-3e043111322d@gmx.org>
From: Andrew Bayer <andrew.bayer@gmail.com>
Date: Tue, 22 Aug 2017 16:44:41 -0400
Message-ID: <CAPbPdOYVJY+A=2QivbRRHsTD+zDqW6xaLFsj5Mp1oXHjZB84Gg@mail.gmail.com>
Subject: Re: How does Groovy decide to coerce a GString to a String at method dispatch?
To: Jochen Theodorou <blackdrag@gmx.org>
Cc: dev@groovy.apache.org
Content-Type: multipart/alternative; boundary="001a11470a3859ea9605575dabf7"

--001a11470a3859ea9605575dabf7
Content-Type: text/plain; charset="UTF-8"

I'll answer in more detail later, but it's a LinkedHashMap.get that's being
called.

A.

On Tue, Aug 22, 2017 at 4:34 PM, Jochen Theodorou <blackdrag@gmx.org> wrote:

> On 22.08.2017 00:53, Andrew Bayer wrote:
>
>> Hey all -
>>
>> I'm working on an issue in Jenkins' Groovy sandboxing logic -
>> https://issues.jenkins-ci.org/browse/JENKINS-46327. The problem is that
>> 'map."some${variable}"' seems to be acting as if the GStringImpl was the
>> key, rather than the String it should coerce to. I've got a feeling this is
>> due to a flaw in our sandbox's method dispatch code somewhere, so I'm
>> trying to figure out how Groovy is deciding to coerce normally. And I can't
>> tell where that would be. =) Anyone got any pointers?
>>
>
> it is legal to call get(String) with a String, but the transformation
> happens during the method call by the runtime. Method dispatch in the meta
> class is deciding about what method is to be taken. It is different for
> static compilation of course.
>
> Now if you have a list of all the get-methods that are available I can
> easily tell you which method will be called and why. So for example if you
> have get(String), get(Object) and get(CharSequence) a call to that method
> with a GString will call the CharSequence method, because that is an
> interface GString is implementing. If that methods would be not there it
> would have been get(String), because String is seen as more near to GString
> than Object for the runtime. Obviously this is not following strictly the
> class hierarchy
>
> bye Jochen
>
>

--001a11470a3859ea9605575dabf7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ll answer in more detail later, but it&#39;s a Linke=
dHashMap.get that&#39;s being called.<div><br></div><div>A.</div></div><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Aug 22, 2017 =
at 4:34 PM, Jochen Theodorou <span dir=3D"ltr">&lt;<a href=3D"mailto:blackd=
rag@gmx.org" target=3D"_blank">blackdrag@gmx.org</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><span class=3D"">On <a href=3D"tel:22.08.2017=
%2000" value=3D"+12208201700" target=3D"_blank">22.08.2017 00</a>:53, Andre=
w Bayer wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hey all -<br>
<br>
I&#39;m working on an issue in Jenkins&#39; Groovy sandboxing logic - <a hr=
ef=3D"https://issues.jenkins-ci.org/browse/JENKINS-46327" rel=3D"noreferrer=
" target=3D"_blank">https://issues.jenkins-ci.org/<wbr>browse/JENKINS-46327=
</a>. The problem is that &#39;map.&quot;some${variable}&quot;&#39; seems t=
o be acting as if the GStringImpl was the key, rather than the String it sh=
ould coerce to. I&#39;ve got a feeling this is due to a flaw in our sandbox=
&#39;s method dispatch code somewhere, so I&#39;m trying to figure out how =
Groovy is deciding to coerce normally. And I can&#39;t tell where that woul=
d be. =3D) Anyone got any pointers?<br>
</blockquote>
<br></span>
it is legal to call get(String) with a String, but the transformation happe=
ns during the method call by the runtime. Method dispatch in the meta class=
 is deciding about what method is to be taken. It is different for static c=
ompilation of course.<br>
<br>
Now if you have a list of all the get-methods that are available I can easi=
ly tell you which method will be called and why. So for example if you have=
 get(String), get(Object) and get(CharSequence) a call to that method with =
a GString will call the CharSequence method, because that is an interface G=
String is implementing. If that methods would be not there it would have be=
en get(String), because String is seen as more near to GString than Object =
for the runtime. Obviously this is not following strictly the class hierarc=
hy<br>
<br>
bye Jochen<br>
<br>
</blockquote></div><br></div>

--001a11470a3859ea9605575dabf7--