Re: [gtk-devel-list] Re: GtkType stuff

[Marius Vollmer <mvo zagadka ping de>]

Tim Janik <timj@gtk.org> writes:

> well, ok, i got the idea. but what do we actually need the flow hints
> for, then? gtk's type system doesn't know about arrays currently, and i
> think you wouldn't want to do this for objects as well, right?

We can use them to add more information to the formal definition of
the Gtk API.  Having a "string" that is "flow inout" would tell us
that the calles functions is allowed to change the string (in place,
by overwriting some of its characters).  The Scheme bindings would
then know that they are not allowed to accept read-only strings for
this parameter.

That would apply exactly in the same way to GtkObjects.  Most
GtkObjects parameters are currently "flow inout" because the functions
are free to mutate a GtkObject.

Flow hints would be useless for the scalar types like "int".

At run-time, the flow hints can help language bindings omit some
unnecessary data conversions.

> > I think the following is cleaner.  It would restrict us to 64
> > fundamental types, but that is still plenty.  We would have: top 24
> > bits: seqno, then 2 bits flow hints, last 6 bits fundamental type.
> 
> trade some seqno bits for that then, so we only have 22 seqno bits available,
> that still makes up more than 4 millions, which is pretty much enough for
> a single program, right? ;)

My motivation was that the fundamental types are a fixed set while we
can have an (conceptually) unlimited number of seqno's.  The
fundamental types still fit easily into 6 bit.
 
> you left out a very important part in your quotation. i originally also
> rewrote the GTK_FUNDAMENTAL_TYPE() macro:
> 
> -#define GTK_FUNDAMENTAL_TYPE(type)      ((GtkFundamentalType) ((type) & 0xFF))
> -#define GTK_TYPE_SEQNO(type)            ((type) > 0xFF ? (type) >> 8 : (type))
> +#define GTK_FUNDAMENTAL_TYPE(type)      \
> + ((GtkFundamentalType) (((type) & GTK_REFERENCE_FLAG) ? GTK_TYPE_POINTER : (type) & 0xFF))
> +#define GTK_TYPE_SEQNO(type)            \
> + (((type) & (~GTK_REFERENCE_FLAG) > 0xFF) ? ((type) & (~GTK_REFERENCE_FLAG) >> 8 : \
> +   ((type) & (~GTK_REFERENCE_FLAG))
> 
> the fundamental idea was, that setting the GTK_REFERENCE_FLAG would
> *change* the fundamental type to GTK_TYPE_POINTER, so that current code
> still handles the passed-by-reference type accordingly.

No.  *My* fundamental idea was that setting flow hints would not in
any way influence the fundamental type, or its mapping to a C type.
GTK_TYPE_POINTER shouldn't be used for anything, btw.

Ok, "flow hints" are a bad term, too.  Let's use "uninited" and
"mutable" qualifiers for a change.

For the static side of the type system: qualifying a parameter as
"mutable" means that the function is allowed to mutate the passed
value.  Qualifying a parameter as "uninited" means that the function
is not allowed to read (parts of) the value before writing to (these
parts of) it.

These qualifiers make only sense for values that are passed by
reference.  But the qualifiers do not influence whether a certain
value is passed by reference or by copying.  The `ref-or-copy'
behaviour is completely defined by the fundamental type.

For example, a "int" is defined to be passed by coyping, so qualifying
it as "uninited" or "mutable" does not make sense.  So it is not
allowed.

But a "string" is passed by reference.  It can meaningfully be
qualified as "mutable", the called function is allowed to mess with
the string.  Qualifying it as "uninited" is probably not possible
because the called function can't figure out the length of the
allocated memory.  Even "mutable" is probably troublesome enough to
just disallow "uninited" and "mutable" strings.  We should use genuine
character arrays for that (with an explicit length).

For the run-time side of the type system, the qualifiers would stick
to the values rather than to the parameters, analogous to the types.

> i'd be interested in hearing owen's comments on this issue, since we
> seem to be stuck wrt the amount of headaches we want to cause for
> the intermediate gtk programmer (occasional widget writers).

The occasional widget writer does not need to provide the detailed
definitions.  They can always be added later by people who care and
know how to do it.