Re: Octave Compatiblity with MatLAB

[Michael Goffioul]

On 9/15/07, David Bateman <address@hidden> wrote:
> 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.

I already thought about this, but I couldn't figure out a good solution
for this. In my opinion, the current handle system in octave is well suited
for a streamed backend like gnuplot where you resend everything for
each plot; in the java context, this handle system is kind of useless,
because you can't share the data between C++ and java, you need
conversion anyway. But I'll continue thinking about it anway.

> Having the handles in Octave allows
> alternative backends, which is what we need until a final choice of
> renderer is made.

If a final decision is made, I don't think it will be a java-based solution
anyway.

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

I'm not familiar at all with that part of the code, so proposing a patch
is not really in my scope for the moment. However, after having looked
at it, I can give some comments about things that should be taken care
of:

1) typed properties: except for radio and color properties, I couldn't
find whether properties are typed; for instance, I can do (it's a CVS
version, but not the latest one)

h = line
set(h, 'xdata', 'my string')

this only produces an error when trying to plot the line, not when
setting the property. Indeed, get(h, 'xdata') returns 'my string'.

2) event system: objects and properties should be able to fire
events, potentially executing some octave code; the most
common events are "property_changed" and "object_deleted".
This corresponds to the listeners I used in my areaseries
implementation

3) property should be changed only if the new value is different
from the previous one: this avoids firing events if the value is
actually not changed

4) dynamic properties: one should be able to add a property to
an object at run-time.

Michael.