Re: Merging graphics branch

[Michael Goffioul]

On Wed, Jun 18, 2008 at 5:11 PM, John W. Eaton <address@hidden> wrote:
> | Thinking about this a little bit further, I realized that using an object
> | to store the linking state (updating or not) won't work, because objects
> | are passed by value in octave, not by reference. IMO, this is something
> | I'm really missing in the other brand and it would allow much more
> | flexible programming patterns: creating objects dynamically (like the
> | regular classes) and being able to pass them by reference (acting
> | like a pointer).
>
> What features of Matlab work like this?  Are you talking about the new
> object system (the one that uses classdef)?  Or that graphics handle
> objects should be implemented differently?

I'm not familiar with this new object system, what I was referring to
is the so-called "schema" OO-paradigm that is present internally
for a few releases (highest version I have access to is 7.3, aka
2006b) and is heavily used in the graphics system.

Looking at documentation on Mathworks web site, what I actually
mean is the "handle class" (I didnt' know this was available), by
comparison with the "value class" that was used in the first
OO paradigm. Value classes are not well suited to store a state
into an object (and being able to modify it), because objects are
passed by value, such that any function that wants to modify
an object state must return the modified object and the caller must
overwrite its own copy. This does not fit well with the concept of
event/property listeners.

> | At first sight, this would mean to having octave_class
> | objects to share the internal Octave_map, instead of copying it.
> | Would this be imaginable?
>
> Would that be the right thing to do for the current object system?

Actually, Matlab supports both. Value classes are what is currently
present in octave. Handle classes are somehow a generalization of
what the current graphics system implements, where objects act
more like pointers.

Michael.