[Octave-bug-tracker] [bug #48428] Support for java.lang.XXX syntax

[Andrew Janke]

Follow-up Comment #18, bug #48428 (project octave):

> Andrew: Yes, that's a place to start, but there really shouldn't be too much
code added there for supporting Java. 
>
>I think the subsref and subsasgn methods in the octave_java class in
ov-java.cc should be doing most of the work. 

I agree. The pt-eval stuff just needs to evaluate the indexed expression
enough to determine whether there is a Java class reference, and the
fully-qualified name of the class. At that point it can hand it off to
ov-java.cc to do the actual work/invocation/value construction.

> Is tree_evaluator::visit_index_expression not handling index expressions
properly for Java calls like 
>
> java.lang.foo.bar
> What needs to be done differently?

visit_index_expression calls evaluate (expr), and by the time the value is
returned, from what I can tell, the left-hand parts of the index expression
have already been resolved to identifiers, Octave packages, or so on. The
determination whether something is a Java reference will need to happen inside
that "evaluate (expr)". I think it needs to happen next to the load-path
evaluation like Mike Miller says: if the resolution doesn't work by looking on
disk for +pkg dirs and M-code files, then it needs to look in the Java
classloaders for class definitions.

> What are the name resolution priority rules in Matlab? If I have a file
'+org/example/name.m' and 'org/example/name.class', which one takes
precedence? 

Surprisingly, the Java class takes precedence.

This is done on a per-class, not per-package basis. So if you have some Java
classes and M classdef files:


a/b/Class1.class
a/b/Class3.class
+a/+b/Class1.m
+a/+b/Class2.m


then a given function may do:

function foo()
  a.b.Class1  % resolves to Java
  a.b.Class2  % resolves to Matlab/Octave
  a.b.Class3  % resolves to Java
end


So the referent of "a.b" can be multiple things in a single scope. This may
take some adjustment in the code.

> Also, in Octave we allow return values to be used as expressions, Matlab
does not allow this. So in Octave an expression like 'uname.sysname' resolves
to a function call 'uname()', and access of the struct field 'sysname'. It
would be nice to preserve that if possible, so something like
'org.example.name' might be a namespaced function, or it might be just a
function named 'org'. 

I think we could write it either way, and it's just up to you folks to choose
what behavior you want in the case where both are defined. Should a function
or variable named "org" shadow the "org" namespace, so "org.example.name" is a
.-reference performed on the output of calling "org"? Or should the existence
of an "org.example.name" class take precedence? Matlab does the latter. Sounds
like Octave does the former for Octave classes; it would be consistent to do
it that way for Java classes too.


octave:13> system('find .');
.
./a.m
./+a
./+a/+b
./+a/+b/Class2.m
./+a/+b/Class1.m
octave:14> a
ans =  42
octave:15> a.b.Class1
error: scalar cannot be indexed with .
octave:15>


I can see a couple arguments for doing it the latter way:
1. Matlab compatibility.
2. Disambiguation: if namespace-qualification took precedence by default,
because Octave allows arbitrary indexing chains, then you could force it to
interpret the "a" in "a.b.c" as a variable or function by doing "(a).b.c" or
"a().b.c". I don't see an easy syntactic way of disambiguating it to be a
namespace qualification if variable/function reference takes precedence by
default.

The big argument against this, of course, is that it would be a breaking
change for existing Octave users. Not something to be undertaken lightly. So
we should probably just do Java support with the current precedence rules, and
consider changing them separately if at all.

> It would be unpleasant if we had to give up arbitrary indexing chains and/or
chained assignments. [...] [M]aybe now we are seeing why this is impossible
for Matlab? I don't know.

I don't see any syntactic reason why we would have to give them up. I think
Java class resolution could work just fine in their presence.

I've always assumed Matlab's prohibition on arbitrary indexing chains was a
design choice to keep people from making "hard-to-read" complex indexing
chains, not a syntactic constraint. I have also never been able to come up
with a simple & clear example why it's not possible.

> What about overloading subsref? Does it cause trouble there?

I do not think overloading subsref would cause a problem here, because an
overloaded subsref would only be called if part of a dot-indexed expression
resolved to a user-defined class. And, if I understand this correctly, that's
an either/or with the expression resolving to a Java class reference, so I
don't think there's a case for interaction.

And with regards to arbitrary index chains, I don't know of any cases where
arbitrary index chains couldn't be converted to subsref arguments; it's a
pretty general signature.

Unless you wanted to get fancy and allow user-defined Octave classes to
generate objects that would be interpreted as Java package or class
references. I had assumed this would just be an internal interpreter feature,
at least for now.

> I'm also interested to know if anyone can see this being extensible, for
example a user oct file registering its own top-level namespace offering
dynamic name resolution.

This idea scares me. :) I like the simplicity of Matlab/Octave code, where
it's usually easy to trace a given function's definition back to its source
code on disk.

> Actual name resolution probably needs to be worked into the existing code in
load-path [...]

I'll look through the load-path code. Thanks.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?48428>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/