Re: the ScriptingMojo

From: Kartik Ohri <kartikohri13(at)gmail(dot)com>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: pljava-dev(at)lists(dot)postgresql(dot)org
Subject: Re: the ScriptingMojo
Date: 2020-08-26 04:44:45
Message-ID: CAASLQ4P47TNiEsuj3ga-vuYeCSBJZmHrPM-49E-X=0T5RTmhKw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pljava-dev

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

In response to

Responses

Browse pljava-dev by date

  From Date Subject
Next Message Chapman Flack 2020-08-26 05:09:19 Re: the ScriptingMojo
Previous Message Chapman Flack 2020-08-25 23:14:54 Re: the ScriptingMojo