Re: GtkType stuff

[Marius Vollmer <mvo zagadka ping de>]

Tim Janik <timj@gtk.org> writes:

> On 26 Aug 1998, Marius Vollmer wrote:
> 

[Names of fundamental types]

> > I don't think that it is that simple.  There needs to be a well
> > defined mapping from fundamental types to types in a certain language,
> > C being the most important.  But this mapping need not be defined by
> > the GtkType<->name mapping of the Gtk run-time.  The purpose of the
> > fundamental types is to identify a set of really basic types that have
> > next to nothing in common and need to be treated each in its own
> > special way.
> 
> yep, but most of them correspond *very* closely to C-related types,
> since those are more or less "wrapped" by glib types, which is what
> Gtk uses throughout the code, the fundamental type names should
> actually adhere to that as well.

I still don't think that this follows.  But I don't insist on being
right for this issue, so let's keep it as it is.

> > > further, the GtkArg system relies on type names to adhere to specifc
> > > namespace conventions, which must not interfere with existing or
> > > temptative argument names, so having a type name like "signal" is
> > > not possible.
> > 
> > Then the GtkArg system clearly has a bug.
> 
> nope, this was needed to distinguish argument names that have a type
> identifier from those that don't.

This is the bug.  You are referring to the treatment of

    "GtkObject::signal::destroy"  <->  "signal::destroy"

right?  "GtkObject" must be clearly identifiable as a type name so
that it can be removed.  The robust thing is to make this
identification based on the context.  There would be no problem with

    "GtkObject::signal.destroy"

    qualified_attr ::= [ id "::" ] attr ;
              attr ::= id { "." id } ;
                id ::= <any character except ":" and ".">

No guessing whether a type named "GtkObject" has already been
registered or not.  The grammer defined by Gtk right now is ambigous
and needs semantic disambiguation.  Not good.

[`Fundamental' cleanups]

> > The "char" type of C is bogus.  Someone once said, "C has no character
> > type, it has byte type that is spelled `c', `h', `a', `r'."
> 
> if i get you right, you argue that GTK_TYPE_CHAR which corresponds to
> the C type `char' should be renamed to GTK_TYPE_BYTE, because the C
> language "char" type should have been named "byte" in the first place?
> and that's the reason you want to change all GTK_TYPE_CHARs into
> GTK_TYPE_BYTE for all existing Gtk code?

Yes.

We can allow code to abuse GTK_TYPE_CHAR for small integers for the
transition period.

> > > a certain signal can for instance have a guchar parameter that
> > > is used for certain flags, or with a defined value range from
> > > 1..4 to indicate certain behaviour (action signals).
> > 
> > They should use GTK_TYPE_BYTE instead.
> 
> let that be -5..+6 or 102..242, you want a GTK_TYPE_SBYTE (signed) also?

No, GTK_TYPE_BYTE would be signed and GTK_TYPE_UBYTE would be unsigned
(just like GTK_TYPE_INT and GTK_TYPE_UINT).

On further thought, I'm not at all sure if need a small integer type
at all.  But using GTK_TYPE_CHAR for non-character stuff should
definitely be considered wrong and GTK_TYPE_UCHAR should go.

> as i said, GTK_TYPE_CHAR corresponds to the C type "char", and unless
> an upcoming C standard replaces the "unsigned char" type with "byte",
> i see no reason why Gtk should do this.

Because it is the Right Thing.  I think everybody agrees that C gets
the character stuff wrong.  "char" was a mistake.  It's a freak of
history.  There might not be a world wide agreement how characters
should actually be represented inside a computer, but a character is
certainly not the smallest adressable unit of memory (or whatever
definition C uses).

We need to be able to distinguish between characters and numbers, even
for ASCII.

> finally, Gtk is implemented in C, and if you want your scheme
> bindings to use "byte" instead of "unsigned char", you can probably
> produce some glue code for that as well, though i'd guess people
> would become majorly confused...

I don't understand this.

[Composite types]
 
> hm, this looks actually quite appealing,

Hey, one out of 8, that's not too bad ;-)

> but gtk_type_register_slist() would probably better be something
> like gtk_type_slist_container() or somesuch, which deals with
> reinvokation for the same pointer type.

I'm not sure if I like the "container" in there...