Re: Namespace resolution in libinterp

[Andrew Janke]

On 7/9/18 8:12 AM, Carnë Draug wrote:
> On 7 July 2018 at 09:35, Andrew Janke <address@hidden> wrote:
> > Hi, Octave maintainers,
> >
> > I'm interested in writing a patch for Octave to support Java-style syntax
> > for invocation of Java constructors and static methods, so you can write,
> > for example:
> >
> >      jstr = java.lang.String('foo');
> >      prop = java.lang.System.getProperty('foo');
> >
> > instead of:
> >
> >      jstr = javaObject('java.lang.String', 'foo');
> >      prop = javaMethod('getProperty', 'java.lang.System', 'foo');
> >
> > This would make Java objects more usable, and increase compatibility with
> > Matlab.
> >
> > Can someone point me to the place in the Octave code (probably in
> > libinterp?) where it handles namespace resolution, so I can use that as a
> > starting point?
> >
> > Cheers,
> > Andrew
> Hi Andrew
>
> I think Matlab already has support for something similar so if you do
> it, can you do it a Matlab compatible way?

Yes, that's the plan.

And possibly as a bonus: Matlab does not currently support referencing 
Java inner classes in this manner. I'll see if I can add support for 
that too, to get one step ahead.
> Also, Octave should be doing automatic wrapping and unwrapping of
> selected types.  One of them is char arrays <-> java strings, so you
> should not need to explicitely do javaObject to get a java string that
> can then be used in other functions.
java.lang.String was just an easy example. I probably should have picked 
java.util.BigDecimal or UUID instead.

(Though, while char[] automatically gets converted to java.lang.String 
when passed in to Java methods, I don't believe that returned 
java.lang.Strings are auto-converted to Octave char[]s. I suspect this 
is by design, and is to preserve object identity, which may be 
significant for java.lang.Strings. Matlab also does this.)

Cheers,
Andrew