Re: Type system query.

[Tim Janik <timj gtk org>]

On Mon, 22 Jan 2001, Michael Meeks wrote:

> 	I use the Gtk type system in gb to handle all of my type
> problems, from base types through user defined type through classes
> and it works very nicely thank you. However, I'm starting to think
> that it may not fit all my needs forever; some problems I am
> considering are:
> 
> 	* public / module private types

what exactly do you mean with "private" types?

> 	* ability to de-register types

types themselves can't be unregistered, just their implementation
can be replaced at runtime (for dynamic types that is).

> 	* multiple concurrent type contexts

something like that is definitely not currently possible (and wouldn't
provide substantial benefits for glib/gtk/oo-apps while introducing
non-trivial overhead).

> 	The latter is rather important already in eg. gnumeric in
> different spreadsheets we can have separate gb execution contexts in
> the same process that mustn't share type data but currently do.
> 
> 	These lead me to believe that either I need to re-implement
> a more generic type system based on the Gtk code; or start at the
> beggining, or hope that somehow GType fixes this.
> 
> 	So; I looked at GType and there are a lot of nice things there
> that I want; however it is clearly still tied to a single type
> context, however there is no particularly good reason for this that I
> can see. If only in theory it should be possible to provide the same
> API with the real guts of the type system exposed genericly relatively
> easily.
> 
> 	I hope this criticism is remotely useful / constructive, since
> I have no time to address these problems before the immenant freeze.
> Also without thinking I have no particularly clever ideas on how to
> address the public / private issues without a fair lot of
> modification. Perhaps in Gtk+ 3.0 ...

well, it is in theory possible to prefix most of the GType API with
an additional GTypeContext* pointer that stores gtype.c internal
locks and static data, however, carrying that on into GValue
and GParamSpec (let alone GObject and GSignal) will be more than nasty.
besides that, an enormous amount of overhead will be introduced
for the standard type system of every glib program, something we'd
definitely not wnt to pay long term.

if you could give a more detailed outline of what exactly your needs
are in gb wrg contexts and privateness of types, there might be a
number of viable ways to achive both goals:
1) provide sufficient add-on hackery to come close to an emulation
   of privateness/contexts that you require
2) provide a contextified version of gtype.c (and maybe selected
   friend .c files) that could be shipped in a contrib section of
   glib (that would at least assure you future maintenance of those
   in parallel with the original gtype.c)

> 
> 	Regards,
> 
> 		Michael.
> 

---
ciaoTJ