Re: update of defs file
- From: James Henstridge <james daa com au>
- To: Karl Nelson <kenelson ece ucdavis edu>
- Cc: Ariel Rios <ariel linuxppc org>, <language-bindings gnome org>, <kenelson elm ece ucdavis edu>
- Subject: Re: update of defs file
- Date: Fri, 25 May 2001 14:33:33 +0800 (WST)
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
> 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
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
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?
] [Thread Prev