Re: dbus glib bindings: deriving from G_TYPE_BOXED, parameterized types
On Mon, 2005-05-16 at 17:29 -0400, Colin Walters wrote: Indeed. I've attached the generic part of the dbus work here. There's dbus-gtype-specialized.[hc], which define an interface for both registering and manipulating specialized types of collections (GArray, GPtrArray, GList), and maps (GHashTable). Any thoughts on this? Should I open a bug? Is it crazy? signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: dbus glib bindings: deriving from G_TYPE_BOXED, parameterized types
On Mon, 2005-05-16 at 15:16 +0200, Tim Janik wrote: On Fri, 13 May 2005, Matthias Clasen wrote: On Fri, 2005-05-13 at 13:01 -0400, Colin Walters wrote: As I just pointed out to Colin, using derivation to model the relation between generic types and their specializations is not really adaequate, since you violate the substitution principle: a Listint can not be substituted for a List, since List promises you to store arbitrary objectds, while Listint can only store ints (which is why generic types systems like the one in Java 5 don't do it like this). what kind of substitution is that? having an abstract or very generic base type (List) and specialization in derived types (Listint) is fairly common practice in inheritance patterns. The principle is that you should be able to treat instances of derived types as if they were instances of the base type. We may need a different way to model the is a specialization of this generic type relation. hm, and exactly why do we need that? Because it is useful information ?! Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: dbus glib bindings: deriving from G_TYPE_BOXED, parameterized types
On Mon, 2005-05-16 at 15:16 +0200, Tim Janik wrote:
On Fri, 13 May 2005, Matthias Clasen wrote:
On Fri, 2005-05-13 at 13:01 -0400, Colin Walters wrote:
As I just pointed out to Colin, using derivation to model the relation
between generic types and their specializations is not really adaequate,
since you violate the substitution principle: a Listint can not be
substituted for a List, since List promises you to store arbitrary
objectds, while Listint can only store ints (which is why generic
types systems like the one in Java 5 don't do it like this).
what kind of substitution is that? having an abstract or very generic
base type (List) and specialization in derived types (Listint) is
fairly common practice in inheritance patterns.
On the instance level, it's pretty common that derivation of
contained types doesn't give you derivation of containers. If you
have:
class ListT () {
int length();
void prepend(T t);
T popFirst(void);
}
Then ListWidget doesn't derive from ListObject because you
can't call prepend(object) on a ListWidget.
Java 5 has the concept of List?. It's legal to call, for example,
length() on a List?, but you can't call prepend() on a List?.
(From memory, I might be getting details wrong.)
So, if we had a G_TYPE_LIST, it would be a List?, not a
ListObject ... the only operations on it would be the ones you
could perform on a list without knowing the type of the contained
objects.
...
List? isn't really that interesting a type as described above,
but with GObject we add an interesting extra: we have classes as
runtime first class objects. There are no interesting *instance methods*
that GTK_TYPE_STATE inherits from G_TYPE_ENUM, but there are
interesting *class methods*. g_enum_get_value(), and so forth.
Similarly, while List? isn't that interesting, ListClass? is more
interesting, because we do have a useful method ... give me
the type of the elements in this list.
So, an extra layer of inheritance:
G_TYPE_BOXED -- G_TYPE_LIST -- G_TYPE_LISTGtkWidget
May actually be modeling something useful. But that doesn't imply
that G_TYPE_LISTGtkButton should inherit from G_TYPE_LISTGtkWidget.
Is G_TYPE_LIST G_TYPE_ABSTRACT or G_TYPE_VALUE_ABSTRACT? You could
argue either way ... G_TYPE_VALUE_ABSTRACT says that there are *no*
interesting instance methods, but there are a couple for GList ...
length() and reverse() that make some sense.
I'd still argue for VALUE_ABSTRACT for the convenience of language
bindings. The language binding is going to either:
A) Convert the GList to a native list
B) Wrap and memory manage the GList
And you can't do either for a raw G_TYPE_LIST.
Regards,
Owen
signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: dbus glib bindings: deriving from G_TYPE_BOXED, parameterized types
[I'm dropping dbus@ from the CC; however I just sent an updated patch there which may be interesting context for this] On Mon, 2005-05-16 at 15:22 +0200, Tim Janik wrote: is this type meant to be abstract (i.e. you'd only use boxed instances which are truly parameterized)? Yeah. 1) Type names can't contain or extending the charset for typenames s no problem. it's an arbitrary limitation made inside gtype.c. Ok, that'd be nice. Currently I'm generating type names like GArray+guint and GHashTable+gchararray+gchararray. I'd like to be able to use GArrayguint and GHashTablegchararray,gchararray. 2) We can't deep derive from G_TYPE_BOXED we didn't see a use for that until now. it can be switched on, the glib code should just be checked for occourances of dependance on flat derivation of boxed types. (i don't expect them to exist though) Right. I am hacking around this at the moment by using qdata on the types. #define DBUS_G_TYPE_STR_STR_HASHTABLE (g_type_build_parameterized (GHashTablegchararray,gchararray)) could you outline what exactly you need besides tearing down the two artifical limitations you described above? (e.g. present code for g_type_build_parameterized(), etc.) Indeed. I've attached the generic part of the dbus work here. There's dbus-gtype-specialized.[hc], which define an interface for both registering and manipulating specialized types of collections (GArray, GPtrArray, GList), and maps (GHashTable). This is neat because now the dbus glib marshalling code can e.g. accept any kind of registered collection, instead of just GArray. For example you could send a GListgchararray and that would be marshalled as a D-BUS array, just like GArraygchararray. I've also attached dbus-gvalue-utils.[hc], which register specialization vtables for GArray, GPtrArray, and GHashTable. To understand this, I'd look at dbus-gtype-specialized.h and get a feel for the interface, then dbus-gvalue-utils.c:dbus_g_type_specialized_builtins_init to see how it's used. /* -*- mode: C; c-file-style: gnu -*- */ /* dbus-gtype-specialized.h: Non-DBus-specific functions for specialized GTypes * * Copyright (C) 2005 Red Hat, Inc. * * Licensed under the Academic Free License version 2.1 * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA * */ #ifndef DBUS_GOBJECT_TYPE_SPECIALIZED_H #define DBUS_GOBJECT_TYPE_SPECIALIZED_H #include glib.h #include glib-object.h G_BEGIN_DECLS GType dbus_g_type_get_collection (const char *container, GType specialization); GType dbus_g_type_get_map (const char *container, GType key_specialization, GType value_specialization); gboolean dbus_g_type_is_collection(GType gtype); gboolean dbus_g_type_is_map (GType gtype); GType dbus_g_type_get_collection_specialization(GType gtype); GType dbus_g_type_get_map_key_specialization (GType gtype); GType dbus_g_type_get_map_value_specialization (GType gtype); typedef void (*DBusGTypeSpecializedCollectionIterator)(const GValue *val, gpointer user_data); typedef void (*DBusGTypeSpecializedMapIterator) (const GValue *key_val, const GValue *value_val, gpointer user_data); gpointer dbus_g_type_specialized_construct(GType type); gboolean dbus_g_type_collection_get_fixed (GValue *value, gpointer *data, guint *len); void dbus_g_type_collection_value_iterate (GValue *value, DBusGTypeSpecializedCollectionIterator iterator, gpointeruser_data); void dbus_g_type_map_value_iterate(GValue *value, DBusGTypeSpecializedMapIterator iterator, gpointeruser_data); typedef gpointer (*DBusGTypeSpecializedConstructor) (GType type); typedef void (*DBusGTypeSpecializedFreeFunc)(GType type,
