From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Pirotte Newsgroups: gmane.lisp.guile.devel Subject: Re: goops - accessors, methods and generics Date: Tue, 5 Mar 2013 20:30:27 -0300 Message-ID: <20130305203027.184e7a66@capac> References: <20130221195139.59f41d13@capac> <20130222201110.0a9e715c@capac> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1362526266 30977 80.91.229.3 (5 Mar 2013 23:31:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Mar 2013 23:31:06 +0000 (UTC) Cc: guile-devel@gnu.org To: Daniel Hartwig Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 06 00:31:29 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UD1KS-0000r2-MD for guile-devel@m.gmane.org; Wed, 06 Mar 2013 00:31:28 +0100 Original-Received: from localhost ([::1]:44153 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UD1K7-00054G-1Q for guile-devel@m.gmane.org; Tue, 05 Mar 2013 18:31:07 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:54732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UD1K2-0004ze-Qe for guile-devel@gnu.org; Tue, 05 Mar 2013 18:31:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UD1K1-0004zw-8m for guile-devel@gnu.org; Tue, 05 Mar 2013 18:31:02 -0500 Original-Received: from maximusconfessor.all2all.org ([62.58.108.13]:58823) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UD1K0-0004xA-Vs for guile-devel@gnu.org; Tue, 05 Mar 2013 18:31:01 -0500 Original-Received: from localhost (unknown [192.168.0.2]) by maximusconfessor.all2all.org (Postfix) with ESMTP id 77330A04C0CF; Wed, 6 Mar 2013 00:30:38 +0100 (CET) Original-Received: from maximusconfessor.all2all.org ([192.168.0.1]) by localhost (maximusconfessor.all2all.org [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id KrD9vmJVzrV5; Tue, 5 Mar 2013 23:59:45 +0100 (CET) Original-Received: from capac (unknown [139.82.89.157]) by maximusconfessor.all2all.org (Postfix) with ESMTPSA id A8170A04C13B; Wed, 6 Mar 2013 00:30:30 +0100 (CET) In-Reply-To: X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 62.58.108.13 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:15867 Archived-At: Hello, > Right, I had misread part of your initial message by focusing on the > lack of a superclass. there is no lack of superclass, your are giving your opinion, which is fine, but i didn't ask, and actually it is a bad opinion: you don't want to [and don't have to by clos spec] create a superclass just because of 1 or 2 slot names. besides, this is a small example, in a large scale system, you may not even know if other classes already ... [and should not need to of course, clos/goops is precisly designed to handle this basic and very common situation]. > However, by not declaring a base module with a superclass in it you are needless > complicating interaction with this set of modules. no, what needlessly complicates things is the unfortunate decision of guilers to mix goops with the module system: you do not want any [by far inferior] module system to interfere with clos/goops. since then you end-up with multiple generics, a pure non sense. then users/developers, like you, start to re-interpret clos, in a wrong way, saying that 'there is no common interface' :) of course there is, 'define-class ... dialog...' twice, on purpose, but guile 'broke it', in the name of its module system, against the clos/goops paradigm. if at least guile designers and goops implementors would have provided a 'switch' so that we could ask that any and all goops related stuff being in a single name space available 'anywhere' at all time [such as guile core functionality is], it would be great, but reading you, it sounds it is more like a religion problem: not much we can do when it comes to that. > You later suggest to import multiple modules and use merge-generics, > but that is highly impractical for a user and yourself. of course, no one should ever merge generics, there should be a single name space for goops stuff. but given it is not the case, what is actually impracticle, for anybody, is the [rather perverse] hidden behavior of guile's module system when I ask to export my accessors [i should always be able to export an accessor i just defined, and never forced to know if someone else also did...]: in this case, i obviously expect the 'importer' to receive at the very least what the module that exports has [such as #< dialog (2)>] but hopefully the 'extended generic with setter'. at the contrary, guile seems to destroy [or recreate?] and export a single class capable accessor: to my opinion, this is a bug [and the worst language core hidden behavior i ever faced in my career: i still can not believe it actually: why on earth guile thinks he knows better then i]. > Consider a user that only imports mg-2, but some how ends up receiving > a . They will not be able to operate on that object without > subsequently importing mg-1 and taking care to merge the generics. mg-2 should export the generic, as opposed to a single class capable accessor. once more, clos/goops do not need a module system, if that is the case, it is because you have a bad oop design and should redesign it better. > >> In your example the two classes share a common interface, but this > >> interface is never defined anywhere. it should, automatically be created, see clos spec: since i use define-class and give the accessor the same name, it must obviously consider one generic function and add the methods appropriatly. export, from any module, should always export the generic, then import always always work. > No, the common interface is not *defined* anywhere. They have similar > yet distinct interfaces. then it is a bug caused by the module system interfering with my design, but i obviously want and have written the source code that asks for a common interface: 'define-class ... dialog ...' twice, on purpose. i do not want to write extra code and/or modules, i don't want a superclass for this case. > your real problem with mg-4 lies in the failure to re-export the binding of > dialog. and here comes the real bug i am facing: a guile bug, not a bug of mine: as said above, i should never have to know whether someone else in his modules, also has used and exported the accessor name. i should always be able to export what i define in my module _and_ guile should always export the generic > Methods are always for generic functions. They operate no other way. sure, i ment one generic per name for the entire system, not per module.. > You are talking about merge-generics, I am talking about a publicly > defined common interface. These are not the same. clos/goops defines the common interface mechanism. by mixing with the guile module system, you destroy this mechanism, than the hidden bug(s) we are talking about that should never appear of course. > what should a user import when they want accessors for all widgets? With your > example, they will have to specifically import every widget-X module *and > merge-generics* just to get at a common enough interface. chances are that this user also wants the all module functionality, not just the 'common' accessors. he obviously will import all the modules that he needs and works with the public interface of each of them. he should not have to merge anything, i merge [since i am forced to] and export, he receives generics. > With a base module making the common interface explicit, there is only > one module to import and you can handle widgets of any class. that will only work in a small system, not a large scale one where you do not know 'everything'. the small example i gave was actually just an example, but it will happen in a real and further more large to very large system. > Within a family of modules, using merge-generics immediately signals the presence > of design issues. the design issue comes from the mixing of the module system with goops and since right now we have no option, the bug in not properly exporting the generic or at least the 'multiple class capable' accessor(s). this export bug also affects defining methods on existing 'core' generics [like get/set which comes with the guile-gnome-platform. Cheers, David