Re: update of defs file

[James Henstridge <james daa com au>]

On Thu, 24 May 2001, Karl Nelson wrote:

>
> Totally off the wall comment.
>
> >
> > (define-object Entry
> >   (in-module "Gtk")
> >   (parent "GtkWidget")
> >   (c-name "GtkEntry")
> >   (implements "GtkEditable"))
>
> The parent seems to use c-names instead of the module/symbol name.
> For all current Gtk symbols this would be "modulesymbol"
> However, this seems odd as lookups in the context would seem to
> go to the object name "Widget".  Will we ever get into a case
> were the entity, Entry in this case, and its module do not don't
> add up to the c-name.  And if not why the c-name field at all?
> If this isn't supposed to be a c-name then it shouldn't look like
> one.
>
> Okay, it is easy to argue that we are using c-names everywhere
> else as arguments because that is what is easiest.  I am not
> really suggesting that we make up some look up rules of
> scoping mechanism to make parent read Gtk->Widget or some
> sillyness.  It just strikes me as odd to define entities like
> "string" and "Widget" and then use the c-name to refer to them
> throughout.

I suggested this change to Ariel.  The reason for using the C name for the
symbol is that it is unambiguous (they have to be, or the libraries
wouldn't compile :).  For some things, it is not clear how much of the
name to treat as the module (ie. in Havoc's original spec, he had an
example of using "Rgb" as a submodule of "Gdk".  Other people might
disagree on that.  So is gdk_rgb_get_visual mapped to Gdk::Rgb::get_visual
or Gdk::rgb_get_visual?).

Generally you would just use the (parent ...) or (implements ...) tags as
a way to look up the corresponding (define-object ...) or
(define-interface ...) section.  Does this sound sensible?

James.