|
From: | Andrew Janke |
Subject: | Re: Namespace resolution in libinterp |
Date: | Mon, 9 Jul 2018 08:50:50 -0400 |
User-agent: | Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 |
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, AndrewHi 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.
java.lang.String was just an easy example. I probably should have picked java.util.BigDecimal or UUID instead.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.
(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
[Prev in Thread] | Current Thread | [Next in Thread] |