Re: GtkType stuff

[Tim Janik <timj gtk org>]

On 28 Aug 1998, Marius Vollmer wrote:

> > > > 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.

the semantics for object arguments (or "options") is not "ambiguous" as long
as certain rules are taken care off:

[GTK_TYPE_NAME::]ARGUMENT_NAME[::ARGUMENT_DATA[::...]]

GTK_TYPE_NAME - a type identifier, registered in gtk's type system, these need
                to be distinguishable through the string identifier itself.
                thus an ARGUMENT_NAME may not consist of a string that would
                ever reveal a value different from `0' for gtk_type_from_name()
ARGUMENT_NAME - an argument name registered within the objects class branch,
                which may not interfere with GTK_TYPE_NAME. thus argument names
                need to not consist of "Gtk*", "Gdk*", or one of the fundamental
                types names, such as "gint", "gchar", "GtkSignal" or "void".
ARGUMENT_DATA - a specific "data" string, used by the argument itself. no
                specific assumptions are being made for this part of the argument
                name.

we've had to make the type portion of the argument names optional to get
typeless argument setters/getters going. in the end, the assumptions we are
making are not so bad, as long as we stick to the above mentioned rules and
keep the current naming scheme for the fundamental types.


> [`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.

C introduces "char" as a type identifier with defined semantics. its not
Gtk's bussiness to lift up and break with that scheme.

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

there's an established code base out there, using the current fundamental
types of gtk. we don't have any good reason to break all of that. i don't
get why you insist on gtk trying to "fix up" C's type names.


> > > > 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).

uhm. till now, i've always considered bytes to be unsigned by default.


> 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.

we got a differentiation between those already. you are still free to use
GTK_TYPE_INT. and even a number can represent a character or an arithmeticall
sign:

43 -> '+'
48 -> '0'
49 -> '1'


> [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...

hm `container' might not be the best idea, but what i'm aming at is something
like

gtk_type_slist_[something] (GTK_TYPE_OBJECT) reveals e.g. 32666 for the first
time it is invoked and does so on subsequent invokations as well, rather
than issueing

Gtk-WARNING **: gtk_type_slist_[something](): type `GtkObject' has already been registered.


---
ciaoTJ