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

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