Re: color_radio_property implementation

[Michael Goffioul]

On 4/25/07, Przemek Klosowski <address@hidden> wrote:
>   | I wanted to keep the java code quite autonomous and usable outside
>   | octave. So using the property database within octave was not really
>   | a solution. Moreover, as java and C++ does not share the same memory
>   | space, it would have been rather complicated and inefficient to have the
>   | properties in C++/octave and have the java part constantly 
> getting/converting
>   | values from C++/octave to java.
>
> Don't know about java and c++ but we used to do that all the time in Tcl and C:
> access the 'property database' (Tcl hash tables, which is the fundamental data
> type in Tcl) via an API in C, and via the array syntax in Tcl. It helped that
> C doesn't have hash arrays so you need to use API anyway, and Tcl-provided
> API was actually pleasant to use.

That's what my code is doing: the database is in Java and the C++ code (Octave)
accesses it.

> In your case, could java use a get/set function approach that instantiates as
> either simple java variable access (when you use it without Octave) or a native
> method, calling the C++ API if used with Octave?

I didn't say it's impossible, but inefficient because of the
continuous conversion
from Octave/C++ to java (mainly converting octave_value objects into Java
equivalent). For instance when doing 3D rotation with the mouse of a complex
surface, this will significantly impacts the performances.

Michael.