|
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.
jwe
[Prev in Thread] | Current Thread | [Next in Thread] |