[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: John W. Eaton
Subject: Re: Learning the Octave interpreter code to implement Java class dot-referencing
Date: Wed, 8 Jul 2020 13:28:58 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 7/8/20 2:27 AM, Andrew Janke wrote:
Hi, Octave maintainers,

A while ago, I took a stab at adding support for dot-reference syntax
for Java classes. (https://savannah.gnu.org/bugs/index.php?41239) I
totally failed, because I don't understand the Octave interpreter code
well enough, and don't have bison/yacc skills.

Can anyone point me at resources for learning about the Octave
interpreter code, or bison/yacc generically, that would help me get good
enough to write a patch for this?

Unless you need new syntax for this feature, I don't think you'll need to know too much about Bison.

Do you want to make expressions like

  java.lang.Double (42)

? Is this similar to invoking static methods for classdef classes? If so, maybe we can do the same kind of thing that we do for those? Or, maybe there is a better way?

Here is what happens for classdef: an expression like

  myclass.method (args)

is evaluated in tree_index_expression::evaluate_n in pt-idx.cc.

When evaluating the first component of the expression ("myclass"), Octave will find and load the constructor for the myclass object. This step happens in the fcn_info::fcn_info_rep::xfind function (around line 740 of fcn-info.cc). But since we don't know at that point whether we are looking up a constructor call or the name will be used to invoke a static method, we get a classdef_meta object (a builtin function object) instead of the constructor function itself.

Then, back in tree_index_expression::evaluate_n, we see that we are indexing an object (classdef_meta) and then gather up the remaining arguments to pass to the classdef_meta subsref method.

So, to handle "java" similarly, we would need some kind of java_meta object with an appropriate subsref method. That object would be inserted in the function table when the octave_java type is installed. Then fcn_info::xfind can return that object when it sees the "java" symbol. Or, if we only have to handle the single word "java", maybe it could just be a special case at the appropriate place infcn_info::xfind to get the precedence right.

I'm not 100% certain, but I think the classdef_meta object is derived from octave_function instead of just being a value so that it can't be wiped out by a variable definition. But if there is a better way, then maybe we can simplify the way the whole classdef_meta thing works at the same time we implement support for java static methods.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]