Re: Graphics properties as objects

[Michael Goffioul]

On 1/10/08, Shai Ayal <address@hidden> wrote:
> > No. Pre and post functions are easily implemented when they correspond
> > to interpreted code (and we'll have to implement that for listeners anyway),
> > but it's rather tricky when the "listener" is a C++ class method (at least
> > I could not figure out a "good" mechanis). So I stepped back and re-used
> > the current system of overloaded <object>::properties::get|set, except
> > that the code is now auto-generated (which makes life much easier).
> > I also removed the registration of static properties into the property map
> > (which is then used only for dynamic properties), because it's not really
> > needed if I keep the previous get|set system; it's even a problem if you
> > want to implement "get (void)" efficiently.
>
> Actually I now remembered that we though about this some time ago
> (July?) and decided that it would not be too much of a limitation to
> have the c++ code use only the generic set function (i.e. void
> <object>::properties::set(octave_value& val)). This will not incur
> much of a performance penalty since the c++ code does not really have
> to set a lot of properties -- it is mainly a viewer so it needs fast
> read access. This way the listeners (or post/pre functions) would work
> for c++ code as well.
> Do you agree to have it this way -- i.e. have only the  void
> <object>::properties::set(octave_value& val) function public?

I'm not sure I fully understand you. In my current implementation, the
specific set_xxx methods end up calling xxx.set(), because of the
overloading of operator=. So in the end, this will trigger any attached
"set" listener, even when called from the C++ code.

We can decide to only make the global "set" method public as you
suggest, but I don't see any added value, because this method simply
end up calling the various set_xxx methods.

What I was talking about is to *write* listeners in C++, which would
more or less correspond to a "class method pointer" (by analogy to
function pointers in plain C). This seemed to me rather tricky and
not really needed with the auto-generated code.

Maybe things will become clearer with my first real and runnable
patch (hope to get it ready in a day or two).

Michael.