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