[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Graphics properties as objects
From: |
Michael Goffioul |
Subject: |
Re: Graphics properties as objects |
Date: |
Thu, 10 Jan 2008 22:14:17 +0100 |
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.
- Re: Graphics properties as objects, (continued)
- Re: Graphics properties as objects, John W. Eaton, 2008/01/08
- Re: Graphics properties as objects, Michael Goffioul, 2008/01/08
- Re: Graphics properties as objects, Michael Goffioul, 2008/01/09
- Re: Graphics properties as objects, Shai Ayal, 2008/01/09
- Re: Graphics properties as objects, Michael Goffioul, 2008/01/09
- Re: Graphics properties as objects, Shai Ayal, 2008/01/09
- Re: Graphics properties as objects, Michael Goffioul, 2008/01/10
- Re: Graphics properties as objects, John W. Eaton, 2008/01/10
- Re: Graphics properties as objects, Michael Goffioul, 2008/01/10
- Re: Graphics properties as objects, Shai Ayal, 2008/01/10
- Re: Graphics properties as objects,
Michael Goffioul <=
- Re: Graphics properties as objects, John W. Eaton, 2008/01/08
- Re: Graphics properties as objects, Michael Goffioul, 2008/01/08
- Re: Graphics properties as objects, John W. Eaton, 2008/01/08
- Re: Graphics properties as objects, Michael Goffioul, 2008/01/08