Delivered-To: lablgtk at yquem.inria.fr
Date: Wed, 31 Oct 2007 11:14:36 +0900 (JST)
Message-Id: <20071031.111436.2004161375.garrigue	 at math.nagoya-u.ac.jp>
To: d0 at wp.pl
Subject: Re: [Lablgtk] Re: Signals - how to inherit GObj.gobject_signals
	properly?
From: Jacques GARRIGUE <garrigue at math.nagoya-u.ac.jp>
In-Reply-To: <fg8kmc$k7g$1 at ger.gmane.org>
References: <fg6136$gqt$1 at ger.gmane.org> <20071030044841.GB29836 at localhost>
	<fg8kmc$k7g$1@ger.gmane.org>
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Cc: lablgtk at math.nagoya-u.ac.jp
Content-Type: Text/Plain; charset=iso-8859-2
Content-Length: 4028

From: Dawid Toton <d0 at wp.pl>

> For me the class type is a tree of arrows and types. When I =

> inherit/include such a type does a copiler look for the righmost leaf=
 to =

> find methods and values of interest?

Yes. Or, more precisely, the class type associated to a class does not
contain the arguments (the signature of class and its type are two
different concepts.) So you never need to apply class types.

This is not to confuse with type parameters. Both classes and class
types may be prefixed by type parameters (between brackets) and they
are always required.

By the way, I couldn't parse Julien's answer on this point...

> > It now uses {< obj =3D obj >} hence the
> > need of val obj =3D obj, which is much more =E9l=E9gant.
> >   =

> As above - is there any deeper reason? If no, here is why I dislike "=
val =

> obj =3D obj" version:
> * as far as I understand: "val obj" adds intermediate step: we have =

> reference to the obj value/field instead of a reference to the actual=
 =

> value of the constructing parameter
> * the constructing parameter is stored in two "places": in the =

> value/field obj and in the actual constructing parameter also availab=
le =

> in the scope of class definition

Actually, the scope for class arguments is only implicit.
They are automatically stored into implicit fields when they are used i=
n
methods, but disappear after construction otherwise.
So, adding "val obj =3D obj" when obj is used in methods doesn't add an=
y
new code, it just makes the obj field explicit, and usable through
inheritance (which in turn avoids field duplication.)
So yes, I would say that writing "val obj =3D obj" is cleaner.

> * personally I find "new class_name obj" construct more readable than=
 =

> {<obj=3Dobj>} (but I'm an OCaml newbie :) )

It is different with respect to inheritance. That is, its type is that
of the object you created, not of the class where the code lies.
Note however that it bypasses both constructor and initializers, which
may be a bad thing in some cases. So I would not say that this kind of
recursion is ugly, just that it is weaker wrt. inheritance.
 =

> BTW: I don't understand: what
>   method private obj =3D obj
> stands for (in lot of LablGTK classes)? I think methods can use the o=
bj =

> that is passed as constructing argument as well. I have an impression=
 =

> that it contributes nothing to the class definition.

This private method is used by the automatically generated code in the
Ogtk*props.ml. There it is declared as "method private virtual obj : 'a=
 obj",
and allows to access the obj field without duplicating it.
Note that since 3.10 this could be replaced by "val virtual obj : 'a ob=
j", =

but this feature was not available in 3.09.

[..]

> I see a problem with your version of the code:
> in print_settings_skel class it is:
>  method copy : 'self option
> but it should return print_settings (not print_settings_skel, as this=
 =

> class should be somewhat hidden - as far as I understand). It seems t=
hat =

> cyclic dependence in class definitions is inevitable.

The point is that 'self is the type of the object created, not of the
class. So it will end up being print_setting if you hide
print_setting_skel. That's the strength of self types, and why they
help avoid cyclic dependences.

> One thing more: =

> http://caml.inria.fr/pub/docs/manual-ocaml/expr.html#htoc71 says that=
 =

> coercion operator :> acts on objects. How is it possible we use it to=
 =

> coerce a value of abstract type? e.g. (obj: [`blah | `blahblah] =

> Gobject.obj :> [`blah] Gobject.obj)
> In Gobject:  type -'a obj

It acts both on object and polymorphic variants, and goes through
other types according to their variance. The "-" above means that obj
is contravariant, and the above coercion is valid because [`blah] is a
subtype of [`blah | `blahblah].

Cheers,

Jacques

_______________________________________________
Lablgtk mailing list
Lablgtk@yquem.inria.fr
http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk