MIME-Version: 1.0
References: 
 <CAASLQ4Mva7dAXiS_c9OLhV4VzNHF=XNKJosuS5gtZTB6b4TW1Q@mail.gmail.com>
 <5F2EC4F4.3080608@anastigmatix.net>
 <CAASLQ4M3pR+ZL+uPvcQ-dAEL2KdH_PGe-_pBhsjvOgN5qvf+aA@mail.gmail.com>
 <5F31EFEC.1080609@anastigmatix.net>
 <CAASLQ4NU9v=nuLDG-LneC68LuqKRXchFckU7mCZT9YQDNKqwvg@mail.gmail.com>
 <5F368380.9070203@anastigmatix.net>
 <CAASLQ4NgH+tXbdUSA8xDh2ct3gAS3xa8V7=E0gcYd+d=m8kujw@mail.gmail.com>
 <5F368A99.6070709@anastigmatix.net> <5F36965C.60707@anastigmatix.net>
 <5F3A7DC6.8090905@anastigmatix.net>
 <CAASLQ4PEgo5Nj0EVsOfGoB96dQFXfFYxrrB0rS1wdad7x_E5fA@mail.gmail.com>
 <CAASLQ4OowXOmnbbbT0Wh1ZkB4h=6JQfC61ojmN07EYnO0QCcow@mail.gmail.com>
 <5F3D32E9.80504@anastigmatix.net> <5F3D36BE.70703@anastigmatix.net>
 <5F3D38F8.7050907@anastigmatix.net> <5F3D3A75.5010304@anastigmatix.net>
 <5F3D3D2E.4070109@anastigmatix.net> <5F3D43BD.4020900@anastigmatix.net>
 <5F3DA48D.7090408@anastigmatix.net>
 <CAASLQ4NGoruXs1+fNsXnsic7cRjqceJ-PiYofG-OMPUWnxDjWA@mail.gmail.com>
 <5F4172F9.4060608@anastigmatix.net> <5F417C68.50702@anastigmatix.net>
In-Reply-To: <5F417C68.50702@anastigmatix.net>
From: Kartik Ohri <kartikohri13@gmail.com>
Date: Sun, 23 Aug 2020 01:49:08 +0530
Message-ID: 
 <CAASLQ4NxaNzZR19dFY6CL80Yz+ntN=LGdRfsX0bOJ_aLKoM-QA@mail.gmail.com>
Subject: Re: the ScriptingMojo
To: Chapman Flack <chap@anastigmatix.net>
Cc: pljava-dev@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000007efd1d05ad7d1133"
Precedence: bulk

--0000000000007efd1d05ad7d1133
Content-Type: text/plain; charset="UTF-8"

On Sun, Aug 23, 2020 at 1:43 AM Chapman Flack <chap@anastigmatix.net> wrote:

> On 08/22/20 15:33, Chapman Flack wrote:
> > Ok, I removed the parallel() and now graal also complains about the SAM
> > cast. This puzzles me because I thought both engines were intended to
> > support that, so I'll keep playing with it a bit.
>
> If I make the attached changes, both nashorn and graal seem to be happy.
>
> It appears that, when invoking a method /of a Java object/, they
> recognize when its parameter type is a SAM interface, and do the magic
> to present a JavaScript function as an implementation of that.
>
> We might just be asking for too many layers of magic when we start by
> binding a Java lambda into the script engine (which probably wraps one
> layer of magic over it to make it look like a JS function), and then try
> to pass a JS function as a parameter needing its own magic wrapping to
> appear as a Java SAM interface, and the engine may not see through the
> first layer of magic to realize it needs to add the second.
>
> "Thing" as a class name is just proof-of-concept of course. :) I had
> been wondering earlier if it might be useful to make PGXSUtils instantiable
> and bind an instance of it into the script; its constructor could take the
> MavenProject and Log and those wouldn't have to be passed around as much.
> It would still be possible to bind selected methods of it directly with
> names of their own for convenience, but other methods could just be
> accessible as utils.method() and I think that would solve this casting
> issue.
>
> Regards,
> -Chap
>

Sounds good to me. I'll make the changes to the PGXSUtils class.
Regards,
Kartik

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

<div dir=3D"ltr"><div dir=3D"ltr">On Sun, Aug 23, 2020 at 1:43 AM Chapman F=
lack &lt;<a href=3D"mailto:chap@anastigmatix.net">chap@anastigmatix.net</a>=
&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">On 08/22/20 15:33, Chapman Flack wrote:<br>
&gt; Ok, I removed the parallel() and now graal also complains about the SA=
M<br>
&gt; cast. This puzzles me because I thought both engines were intended to<=
br>
&gt; support that, so I&#39;ll keep playing with it a bit.<br>
<br>
If I make the attached changes, both nashorn and graal seem to be happy.<br=
>
<br>
It appears that, when invoking a method /of a Java object/, they<br>
recognize when its parameter type is a SAM interface, and do the magic<br>
to present a JavaScript function as an implementation of that.<br>
<br>
We might just be asking for too many layers of magic when we start by<br>
binding a Java lambda into the script engine (which probably wraps one<br>
layer of magic over it to make it look like a JS function), and then try<br=
>
to pass a JS function as a parameter needing its own magic wrapping to<br>
appear as a Java SAM interface, and the engine may not see through the<br>
first layer of magic to realize it needs to add the second.<br>
<br>
&quot;Thing&quot; as a class name is just proof-of-concept of course. :) I =
had<br>
been wondering earlier if it might be useful to make PGXSUtils instantiable=
<br>
and bind an instance of it into the script; its constructor could take the<=
br>
MavenProject and Log and those wouldn&#39;t have to be passed around as muc=
h.<br>
It would still be possible to bind selected methods of it directly with<br>
names of their own for convenience, but other methods could just be<br>
accessible as utils.method() and I think that would solve this casting<br>
issue.<br>
<br>
Regards,<br>
-Chap<br></blockquote><div><br></div><div>Sounds good to me. I&#39;ll make =
the changes to the PGXSUtils class.=C2=A0</div><div>Regards,</div><div>Kart=
ik</div></div></div>

--0000000000007efd1d05ad7d1133--