Re: Learning the Octave interpreter code to implement Java class dot-referencing

Hossein Sajjadi <[email protected]>
Newsgroups gmane.comp.gnu.octave.maintainers
Message-ID <CAEuvCVO28HOrvV9mU49WW1sASgpAQNe1fRgD7Wz-GmciBM0JEw@mail.gmail.com>
On 7/12/20, Andrew Janke <[email protected]> wrote:
>
>
> On 7/11/20 10:01 AM, Hossein Sajjadi wrote:
>>
>> This idea can be extended further and an Octave classdef object that
>> is inherited from base java object can be sent to java. But it
>> requires that on-the-fly java classes are generated from octave
>> classdef classes.
>>
>
> The thing is, in this case, the Java External Interface for Octave is
> already written, and it works fine. The issue is just that you have to
> explicitly call the `javaObject(...)` and `javaMethod(...)` functions,
> instead of using `myjavapackage.foo.bar.Class.Method(...)`
> dot-referencing syntax in your M-code, which I think is solely in the
> domain of the interpreter. All the other pieces are already in place.
>
> Cheers,
> Andrew
>

It already is written  when no classdef implementation existed. The
`octave_java` as pointed out in the previous post is related to
javaObject and javaMethod. 'octave_java' is one of pieces of the
proposed design . I think the current  interpreter has all of things
to be used in the implementation of java dot referencing. If MATLAB
compatibility is important all things should be implemented as
classdef. Defining special rules for evaluation of expressions
containing java objects complicates the evaluator and may have
performance implications.
-- 

Sincerely,
Hossein
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.