Re: New 'GObject' as base for GtkObject?

[Owen Taylor <otaylor redhat com>]

Karl Nelson <kenelson@ece.ucdavis.edu> writes:

> > > - abstract callbacks in some way. A callback is not necessarily a
> > >   function pointer.
> > >
> > 
> > This is a good idea, complicated because you also have to abstract
> > marshallers. Has any discussion gone in to how to do this?
> > 
> > What about a signal-signature->marshaller lookup table used to find
> > alternate marshallers.  Then an additional flag passed to
> > gtk_signal_connect_still_more_full() that specifies which marshaller
> > set to use. So default handlers and connections done with
> > gtk_signal_connect() use the default marshaller still. C++ bindings
> > could pass an instance/memberfunction pair instead of a GtkSignalFunc
> > to connect_still_more_full(), and then provide marshallers that 
> > invoked the instance/memberfunction pair.
> 
> I have discussed a number of ideas with developers on the gtk+ irc.
> Things like separating the marshaller from the argument launcher
> have also been discussed.  In Libsigc++, the marshaller is a
> function that takes the new return value and old one
> and combines them together, returning a code on whether to
> continue the emission or not.  This would avoid a lot of calls 
> to the emission stop.  (The launcher is the slot
> that processes the arguments from a list to a function call again.) 
> If you eleminate the global lists from the emission process the 
> system would be thread safe without needs for a global lock 
> like gtk+.  However, the conclusion always seems to be "it would 
> have been nice, but it is too late now."

Eh? I didn't get that opinion. I was certainly very positive
on the idea of adding the abilility to have "TRUE return stops emission",
and I think Tim was at least moderately in favor of that.

This does not mean that we would get rid of global emission
lists, but if we moved GtkObject it to a libgobject, I'd definitely
imagine adding the necessary locks to make it GLib-style thread
safe. (That is, the internal data structures would be thread safe) - 
and  make the emission lists per-thread.
 
> I personally think that it would be great if the object system
> and signal system got a good long design review, but I don't think
> that is possible as no one would ever agree.  
> 
> However, I think this discussion is premature (or grossly too
> late,)  splitting and redesigning the object system from gtk+
> is really material for 2.0 of the library.  In order for
> it to be usable to the wrappers and ensure flexiblity, we
> can't just say here is code and use, so elegance of
> design has to be made.  Otherwise you end up in the same situation
> as today.
> 
> For example,  from the C++ prospective (these cover all of gtk+
> and some reflect on the object system)
> 
> - you can't use static cast at all in C++ because the gtk+ object
>   model has no concept of casting to primitive object and use
>   its functions.

Eh? I don't follow. If you map a GtkObject onto a static C++
heirarchy, then static casts work fine. 

I mean ... certainly if you create a Gtk_Button structure in gtk--
you can do:
 
   button.add(label)

which is doing implicit static casts...

> - The type argument interface is almost worthless as it does
>   not have any way of typesafety, nor can it be easily cast as
>   a stream.  (args interface should take float, int, or strings
>   and handle them all instead of casting to what is exected and
>   barfing!)   In otherwords be typesafe and if you can't be
>   able to take all inputs and deal with them safely. 

Hrmm? I guess you are referring to the varargs interfaces in 
GTK+ ... but those are going to be wrapped anyways by a
language binding.

For the C the typesafe interfaces to argument setting are
the accessors gtk_container_set_border_width(). 

Adding something like:

 gtk_object_set_int_arg (GtkWidget *widget, char *arg, int value);

would only give you run-time type-safety anyways.

> - there is not way to make a looks/works like something that
>   isn't exactly that type.  (poor abstractions)  (Okay this
>   is my glist beef and I will carry to my grave.)

No, we aren't going to virtualize GList, sorry. GList is the 
C mapping for the abstract concept of a list of items. Language
mappings should map GList onto the appriorate list type for
their language.

> - Too many damn fragments which all have their own reference
>   interface.  Why can't they all come from a very simple light
>   interface.

Well, perhaps we can address this somewhat if we create a lightweight
GObject, but there is definitely a need for even lighter "objects" - 
things that don't present inheritance or virtualization at all.
(e.g. GString). This was basically the idea of the BOXED type
that Marius introduced though never fully implemented. That is,
you have a "object" represented with a pointer, and there are
two functions that act on 

> - lack of multiple inheritence.  Really it is much more OO to
>   define an interface (which may have some data like a signal)
>   and then have every thing that has that interface inherite from
>   it.

Multiple inheritance is just a complete struggle to implement as
compared to single inheritance, and doesn't map well onto C.
Also, there is considerable school of thought out there 
(which I belong to) which says that multiple-inheritance of
implementation is generally a worse way of doing things than
aggregation.

Hopefully, by introducing interfaces to GtkObject (as planned
for 1.4) we'll get most of the advantages of MI without most
of the complexity. 

> - provide hooks to wrappers (meaning the wrappers need to be 
>   thought out in advance.)  We don't want to have all the overhead of
>   checking and dynamic gtk+ casting all the time because we are a
>   strongly typed language and thus we can give you the exact type needed.

? There is no need to use the checked casts external to GTK+ 
if you don't want to.

Internal to GTK+, yes the overhead will be there (unless the user
compiled with --disable-debug) ... but if it isn't an issue
for GTK+ in C, it shouldn't be an issue for C++. If it is an
issue, than we need to address that for C ... after all, this
overhead is only sanity checking so if necessary we could
make --disable-debug the default. (Not that I believe that
it _is_ an issue.)

Regards,
                                        Owen