Re: Easy way to interpret octave_value as XXX?

[Rik]

On 12/18/2012 08:54 AM, John W. Eaton wrote:
> On 18-Dec-2012, Rik wrote:
>
> | I used Michael's solution here
> | (http://hg.savannah.gnu.org/hgweb/octave/rev/317f4857c1e1).  I was
> | modifying class() to return the true Java class name rather than merely
> | "octave_java".  It was a one-liner call to jobj->java_class_name () as soon
> | as I actually had it coerced into the correct class.
>
> For this particular case, there is already an octave_value::class_name
> method that forwards to rep->class_name.  So I would do something like
> the attached patch so that octave_java::class_name will work much like
> octave_class:class_name.
>
> Maybe we should also deprecate "java_class_name" in favor of using
> "class_name"?
I was trying to keep things simple, but this the right way to go now that
Java is in the core.  There is a lot of overlap between what the Java
Interface wants and what the classdef stuff will eventually want.  I've
been trying to keep the Java stuff mostly contained until there is more
clarity on the classdef implementation.  In that regard, you probably
noticed that I added shim functions scripts/general/methods.m and
scripts/general/fieldnames.m  The architecture is trivial

if (! isjava (ob))
  call existing C++ function
else
  call Java function
endif

I decided that this could easily be removed when/if we want to move direct
Java calls out of ov-java.cc where they are currently segregated.

As it happens, the octave_java class was already keeping track of the java
class name so the changes you suggested were easy.  Confusingly, however,
the private variable was named java_type so I renamed it.  The code was
also using tests on class_name == "octave_java" to determine if an object
was a Java object.  I replaced all of those with is_java () tests.  See
changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/f28b3dcbaa9a).

--Rik