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

[Andrew Janke]

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

I forgot to mention what I think the actual resolution algorithm should be. I
think it should be:

Given a dot-indexed expression "a.b.c.d.e.f" that is at the start of an
indexed expression:

If "a" does not resolve to an Octave variable or function, then:

1. Consider each prefix of the dot-indexed sequence (e.g. "a", "a.b", "a.b.c",
"a.b.c.d", ...)
2. If there is a Java class in the JVM's classloaders that exactly matches
that fully-qualified name, then it is a Java class reference.
3. Once a class reference is found, keep considering subsequent .-indexes to
see if they are inner classes of that class.
4. Once there are no more inner class .-references, you have the Java class
reference that stuff should be dispatched on.
5. Consider the single next indexing expression
 a. If it is a ()-index, then that is a constructor call.
 b. If it is a .-index, then that is a static field access or static method
call.
 c. If it is a {}-index, that is an error.
 d. If there is no next indexing expression, then it is a zero-argument
constructor call.
6. Take the resulting value and evaluate the remaining chained indexings as
normal.

5.b.i) If there are multiple overloaded static methods of the same name,
choose between them based on their signatures and the input arguments using
the existing mechanism for choosing between overloaded non-static Java
methods.

This logic would be split between pt-eval, load-path, and ov-java as
appropriate.

Examples:

Given a Java class "a.b.c.Foo" with static field "fld" and static method
"meth", and without a "bar" static field or method, then:

* "a.b.c.Foo" is a zero-arg constructor call.
* "a.b.c.Foo()" is also a zero-arg constructor call.
* "a.b.c.Foo.fld" is a field access on "fld".
* "a.b.c.Foo.fld(ix)" is a field access on "fld", whose value is then indexed
into using normal Octave Java value ()-indexing.
* "a.b.c.Foo.meth" calls meth() with zero arguments.
* "a.b.c.Foo.meth(42)" calls meth() with the argument 42.
* "a.b.c.Foo.meth(42)(3)" calls meth(42) and then ()-indexes into the returned
value using normal Octave Java value ()-indexing (array element access).
* "a.b.c.Foo.meth(42).bar" calls meth(42) and then .-indexes into the returned
value using normal Octave Java value .-indexing (field access).
* "a.b.c.Foo.bar" raises an error about "no static field or method named 'bar'
in class 'a.b.c.Foo'". It does not call the zero-arg "Foo()" constructor and
then try to access ".bar" on the resulting object.
* "a.b" results in an "'a' undefined near line 1 column 1" error, the way it
currently does. It does *not* result in referring to a Java package.
* "a.b.c" results in an "'a' undefined near line 1 column 1" error, the way it
currently does. It does *not* result in referring to a Java package.

The one about "a.b.c.Foo.bar" not calling the "Foo()" constructor is a bit of
a discontinuity in the syntax pattern, but I think it results in more
understandable error messages, and avoids some ambiguity. If you really want
the 0-arg constructor and then to index into its results, you could call
"a.b.c.Foo().bar".

    _______________________________________________________

Reply to this item at:

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

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