[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