MIME-Version: 1.0
References: 
 <CAASLQ4Mva7dAXiS_c9OLhV4VzNHF=XNKJosuS5gtZTB6b4TW1Q@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>
 <CAASLQ4MBWQeFLdAPNcsgcpLyekU5X=ExQUuGgE49AUFdEYJr8g@mail.gmail.com>
 <5F41943D.9080707@anastigmatix.net>
 <CAASLQ4P5oEx0DLoDLEOAkZSwffU2eS2+NKbevgYqpknHGucaTw@mail.gmail.com>
 <5F427604.5010103@anastigmatix.net>
 <CAASLQ4Nr3MPQuZziVU+89ULZ=BgQjaPPnCLsyPR3mhW-eWoOBw@mail.gmail.com>
 <5F42A71F.8000002@anastigmatix.net>
 <CAASLQ4PkP017rtyUswKO_TCiNmnica-nrQHBgggFw-U_9MstUg@mail.gmail.com>
 <5F459B6E.3020803@anastigmatix.net>
In-Reply-To: <5F459B6E.3020803@anastigmatix.net>
From: Kartik Ohri <kartikohri13@gmail.com>
Date: Wed, 26 Aug 2020 10:14:45 +0530
Message-ID: 
 <CAASLQ4P47TNiEsuj3ga-vuYeCSBJZmHrPM-49E-X=0T5RTmhKw@mail.gmail.com>
Subject: Re: the ScriptingMojo
To: Chapman Flack <chap@anastigmatix.net>
Cc: pljava-dev@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000004e57af05adc07b47"
Precedence: bulk

--0000000000004e57af05adc07b47
Content-Type: text/plain; charset="UTF-8"

Hi!


> I have noticed a quirk (in nashorn anyway, haven't tried graal) where
> even the methods that are declared in the superclass can have trouble
> referring to each other as this.method() even though calling them from
> outside as bigobj.method() works fine. The dynamic nature of javascript
> allows a workaround: they can refer to each other as bigobj.method().
>
> I think that should be workable, as we will only be making one instance
> of one of these objects, and probably saving that in an outer var, maybe
> pgxs, and so if its JS-implemented methods internally refer to each other
> it can just look like methoda: function() { pgxs.methodb(); }.
>

I had done the similar experimentation as you did with similar results in
Nahorn and Graal.
Both did not work when I tried to use this. I was able to call the methods
externally
but not inside each other. But that outer variable work around gives the
desired
results and I will use it that way. Thanks.

Also, I had another question: is there any particular reason that compiling
and linking should
be two different commands. To me it appears to be another one of nar maven
quirks.
Compilers by default compile and link in a single step. It seems nar maven
overrides it due to
reason. Since, there is no configuration to suggest that this is desired I
am a bit confused.
Do we want to compile and link in different steps ?

Regards,
Kartik

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div>Hi!</div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">I have noticed a quirk (i=
n nashorn anyway, haven&#39;t tried graal) where<br>
even the methods that are declared in the superclass can have trouble<br>
referring to each other as this.method() even though calling them from<br>
outside as bigobj.method() works fine. The dynamic nature of javascript<br>
allows a workaround: they can refer to each other as bigobj.method().<br>
<br>
I think that should be workable, as we will only be making one instance<br>
of one of these objects, and probably saving that in an outer var, maybe<br=
>
pgxs, and so if its JS-implemented methods internally refer to each other<b=
r>
it can just look like methoda: function() { pgxs.methodb(); }.<br></blockqu=
ote><div><br></div><div>I had done the similar experimentation as you did w=
ith similar results in Nahorn and Graal.=C2=A0</div><div>Both did not work =
when I tried to use this. I was able to call the methods externally=C2=A0</=
div><div>but not inside each other. But that outer variable work around giv=
es the desired=C2=A0</div><div>results and I will use it that way. Thanks.<=
/div><div><br></div><div>Also, I had another question: is there any particu=
lar reason that compiling and linking should</div><div>be two different com=
mands.=C2=A0To me it appears to be another one of nar maven quirks.</div><d=
iv>Compilers by default compile and link in a single step. It seems nar mav=
en overrides it due to</div><div>reason. Since, there is no configuration t=
o suggest that this is desired I am a bit confused.</div><div>Do we want to=
 compile and link in different steps ?=C2=A0=C2=A0</div><div><br></div><div=
>Regards,</div><div>Kartik</div></div></div>

--0000000000004e57af05adc07b47--