Re: general c++ question

[Shai Ayal]

On 8/27/07, John W. Eaton <address@hidden> wrote:
> On 27-Aug-2007, John W. Eaton wrote:
>
> | On  3-Jul-2007, Shai Ayal wrote:
> |
> | | On 7/2/07, John W. Eaton <address@hidden> wrote:
> | | > On  2-Jul-2007, Shai Ayal wrote:
> | | >
> | | > | OK, so it seems this isn't possible (google also seems to say this).
> | | > | Unless there is some big objection, I will remove the nesting, i.e.
> | | > | class XXX_properties will not be nested in class XXX.
> | | >
> | | > Before you do that, can you please explain why do you need to declare
> | | > the function that returns properties before the property class has
> | | > been fully declared?
> | |
> | | I thought of adding functions to access the individual XXX_properties
> | | classes, so the a back-end written in c++ could gain access to these.
> | | It seemed to me that the gh_manager class was a good place for these
> | | functions since it would allow gaining access to properties using only
> | | the handle. I though of using something similar to the ocave_value way
> | | -- add const XXX::XXX_properties& XXX_properties_value() functions
> | | However, all XXX_properties depend on base_property which in turn
> | | depends on gh_manager which means I have to forward-declare the
> | | XXX_properties before gh_manger. Since this is impossible to do with a
> | | nested class my solution was to un-nest XXX_properties from XXX
> |
> | How about the following change instead?  This makes it possible to
> | move the declaration of gh_manager after all the graphics object types
> | have been declared.  If this change makes it possible for you to do
> | what you need with nested classes, then I propose that we also rename
> | the properties classes so that they are just figure::properties
> | instead of figure::figure_properties (for example).
> |
> | jwe

In a patch I submitted some time ago with the subject "exposing
graphics object properties" I outline what is the call graph for
getting properties. I quote from that mail:

-------
I attach a patch who's purpose is to expose the properties of the
graphics objects. The purpose of this patch to allow access to
properties as in:

if (gh_manager::get_object (h).isa () == "image")
  image_properties ip = gh_manager::image_properties_value (h);

It turned out it involved quite a lot of new functions and
"declaration acrobatics" where function definitions had to be moved
because of forward declarations. To illustrates, the above functions
call will set in motions the following:

gh_manager::image_properties_value
gh_manager::do_image_properties_value
graphics_object:::image_properties_value
virtual base_graphics_object::image_properties_value

in all these calls the image_properties class is passed by value. I
also had to un-nest the properties classes from inside their
respective object classes in order to allow their forward
declarations.

I do not like my patch, I hope it turned out this complicated because
of some oversight by me or my lack of c++ knowledge. Please comment on
it.

---- end of quote.
as you can see, graphics object & base_graphics_object also need to be
aware of the properties in the scheme that I ended up with. So just
moving gh_manager to the end of the declarations would not do.

Shai