octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Graphics code small questions?


From: John W. Eaton
Subject: Re: Graphics code small questions?
Date: Mon, 14 Jan 2008 14:40:33 -0500

On 14-Jan-2008, Michael Goffioul wrote:

| On 1/14/08, John W. Eaton <address@hidden> wrote:
| > On 14-Jan-2008, Michael Goffioul wrote:
| >
| > | 1) Most of the code within the object classes is common; should we
| > | try to generate this code as well?
| >
| > It would be OK with me to generate any code that follows the same
| > patterns.  But I'd like to be careful to avoid making the script that
| > generates the code overly complex to deal with any special cases (I
| > haven't looked, so I don't know whether this might be a problem).
| 
| Most of the code of classes inherited from base_graphics_object is
| common (actually, I don't get why this code is repeated in each
| inherited class). Another possibility would be to move the common
| code into base_graphics_object class. For instance, instead of the
| current remove_child implementation, I'd propose the following:
| 
| virtual void remove_child (const graphics_handle& h)
| {
|   if (valid_object ())
|     get_properties ().remove_child (h);
|   else
|     error ("base_graphics_object::remove_child: invalid graphics object");
| }
| 
| What do you think about it?

I think that change is fine.  I think the reason it was done this way
originally is that at first we did not have a get_properties method,
and I needed some way to make the dispatch work.  I remember being
slightly annoyed that I was duplicating these functions, but at the
time I didn't see another way to do it.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]