[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Learning the Octave interpreter code to implement Java class dot-ref
John W. Eaton
Re: Learning the Octave interpreter code to implement Java class dot-referencing
Wed, 8 Jul 2020 13:28:58 -0400
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
? 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
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.