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 m
On Mon, 2005-05-16 at 07:35 -0700, Dave Benson wrote:
> "List promises you to store arbitrary objects"..
> How does memory management work? How does the client
> check the type of elements in the list?
If the client knows the GType of the list, then with a suitable API like
the one I proposed it
[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) Typ
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 r
On Mon, May 16, 2005 at 10:10:17AM -0400, Matthias Clasen wrote:
> 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 mo
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 r
On Fri, 13 May 2005, Colin Walters wrote:
However, hand-defining various types such as GArray is mildly
painful; it's even worse for the GHashTable cartesian product. Although
I imagine for GHashTable not all of those will be in use; e.g. everyone
seems to be using string keys only, and not using
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 List c
Le vendredi 13 mai 2005 Ã 13:01 -0400, Colin Walters a Ãcrit :
> Hi,
>
> It's rather timely that Owen mentioned the topic of deriving from
> G_TYPE_BOXED in the Cairo discussion.
>
> I've been working on the GLib bindings for the D-BUS messaging system
> (http://www.freedesktop.org/Software/dbus
On Fri, 2005-05-13 at 13:01 -0400, Colin Walters wrote:
> Hi,
>
> It's rather timely that Owen mentioned the topic of deriving from
> G_TYPE_BOXED in the Cairo discussion.
>
> I've been working on the GLib bindings for the D-BUS messaging system
> (http://www.freedesktop.org/Software/dbus). The
Hi,
It's rather timely that Owen mentioned the topic of deriving from
G_TYPE_BOXED in the Cairo discussion.
I've been working on the GLib bindings for the D-BUS messaging system
(http://www.freedesktop.org/Software/dbus). The core problem I am
running into is that D-BUS has a fully recursive typ
11 matches
Mail list logo
