Delivered-To: lablgtk at yquem.inria.fr To: lablgtk at math.nagoya-u.ac.jp From: Dawid Toton Date: Wed, 31 Oct 2007 02:10:15 +0100 Lines: 110 Message-ID: References: <20071030044841.GB29836 at localhost> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <20071030044841.GB29836 at localhost> Subject: [Lablgtk] Re: Signals - how to inherit GObj.gobject_signals properly? Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Length: 5052 Thank you for looking at my code! (further questions below) >> One thing more I don't understand worries me: why it is legal to write >> inherit [[> GtkPrintOperation_types.print_operation]] GObj.gobject_signals >> >> when "[[> GtkPrintOperation_types.print_operation]] GObj.gobject_signals" >> is sort of Gobject.obj->object and needs to be feeded with some obj to >> become an OCaml object (that surely can be inherited). >> Now it looks as if it inherits "Gobject.obj->object" function. >> > It is only authorized in signatures where the types of the class' arguments > (a.k.a. implicit instance variables) are abstracted by the class' parameters > (i.e. the types before the class' name, those between '[' ']')). > So if arguments' types are already abstrated (understand bound or known), > no need to write them right. > > 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? According to what you've written the following declaration is incorrect: class print_settings : 'obj Gobject.obj -> object constraint 'obj = [>GtkPrintOperation_types.print_settings] inherit print_settings_skel (* this shouldn't be allowed - type of class argument is not known *) end becouse print_settings_skel has arguments that need to be bound. > Also, see the attached files, I have modified the classes so they are no > longer recursive, which is ugly. Is it only matter of aesthetics? If so, I'd rather stay with recursive definitions, becouse: * if the code is handwritten: 1. need to imagine/draw a tree of dependency and do topological sorting for each change in the interface (that involves just defined classes) 2. eventually (after some enhancements made to the API), when a cycle appears, one needs to change all "class" to "and" to make the definition recursive * when the code will be generated: need additional code that does this topological sorting (and need to expect cyclic graph case as well) with no practical benefit So it's easier and cheaper to have recursive definition from the beginning. (Initially I favoured this choice, becouse this way it resembles the behaviour of popular OO languages.) > It now uses {< obj = obj >} hence the > need of val obj = obj, which is much more élégant. > As above - is there any deeper reason? If no, here is why I dislike "val obj = 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 available in the scope of class definition * personally I find "new class_name obj" construct more readable than {} (but I'm an OCaml newbie :) ) BTW: I don't understand: what method private obj = obj stands for (in lot of LablGTK classes)? I think methods can use the obj that is passed as constructing argument as well. I have an impression that it contributes nothing to the class definition. > Note also that *_skel take now a [closed polymorphic variant type] Gobject.obj, > this is due to *.copy which closes the p.v.t.. > In my code GtkPrintOprtaionProps.PrintSettings.copy doesn't close the p.v.t.: external copy : [>`printsettings] obj -> print_settings Gobject.obj option I can imagine it could be wrong if gtk_*_copy functions are not aware of the actual type of the whole object, i.e. if it could cut away a part of the object that belongs to a subclass. After a quick look at GTK docs I suppose that *_copy functions are defined for final (not subject to inheritance) classes. Thus I think that GtkPrintOprtaionProps.PrintSettings.copy and similar don't need to close the type. If it's really necessary to close the variant type then I'd need to maintain the functions as having exceptional translation from C code. 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 that cyclic dependence in class definitions is inevitable. > Besides a few Gobject.obj were missing after several p.v.t. in #as_*. > > That's all, > keep up the good work :) > > > Thank you. It's nice to see my work considered as good (it raises my spirits after prolonged coding without a single page printed from OCaml :) ). 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 Dawid Toton _______________________________________________ Lablgtk mailing list Lablgtk@yquem.inria.fr http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk