Re: Octave Compatiblity with MatLAB

[Michael Goffioul]

On 9/14/07, David Bateman <address@hidden> wrote:
> Michael,
>
> Can we open a discussion on the split of the graphic handles between
> octave and java? At the moment you have duplicated a large part of the
> handle system in Octave in java, to prevent needless transfers of data
> from Octave to Java.  However, this means a duplication of effort. What
> would be needed to allow the existing handle system in Octave to be used
> completely with a means of synchronizing the data between it and your
> java backend. In that way your java backend would be minimally
> intrusive, the switch to it in the long run might be facilitated and
> finally there would be less of a split of effort (for example your
> barseries changes in jhandles would done in Octave)..

Initially, the idea was to make JHandles still usable outside octave; hence
it had to provide its own handle system (which I started to develop before
octave had its own).
Now, it's a fact that I need to keep the object properties in the Java
world, to avoid doing constantly java/C++ conversion in operations like
3D rotation. Keeping a C++ and java version in sync is IMO additional
work that is not worth the effort. Most core objects already honor a
large set of properties and have the right behavior (for instance setting
XLim on an axes object also change XLimMode). Non-core objects
should be written entirely in Octave, like I did for areaseries object.
The barseries object is not something you should take as an
example, because I'll thrown it out and replace it with an octave-based
implementation. Actually, I'd be glad if the octave handle system would
support property listeners and runtime properties (property added to
objects at runtime): this would allow to implement most specialized
graphs in octave independently of the graphic backend (which would
then limits to provide the core objects).

Michael.