Re: Octave Compatiblity with MatLAB

[David Bateman]

Michael Goffioul wrote:
>
> 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 that Octave has its only handle system JHandles shoudl use as much
of it as possible.

> 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. 

Yes I can understand the disadvantage of the synchronization code.
However does it out weigh the advantage of reusing the maximum amount of
the octave graphic handles code as possible. If there is one thing
that'll make jhandles harder to accept as the Octave renderer (at this
point in time) it will be this. Having the handles in Octave allows
alternative backends, which is what we need until a final choice of
renderer is made.

> 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). 

I've been using jhandles recently (except for printing) and I agree that
it really does respect the matlab behavior better than the other
alternatives I've tried (though I think the subplots are too small :-) )..

> 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. 

Ok, barseries I see are implemented in java at the moment. What would it
take to bring these into Octave core? Probably the next point addresses
that..

> 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).

I think both Shai and John said they liked this. Could you propose a
patch? If so I think it would probably be accepted.

D.