From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.user Subject: GOOPS and Code Complexity Date: Tue, 09 May 2006 11:43:20 +0200 Organization: LAAS-CNRS Message-ID: <87fyjjr0sn.fsf_-_@laas.fr> References: <66e540fe0605041226q2a570820xc4eb08fc68051eb5@mail.gmail.com> <87fyjmrbv6.fsf@ossau.uklinux.net> <66e540fe0605070237r12b1ee34i22dfb7b63a2b1dd8@mail.gmail.com> <87ody73a37.fsf@laas.fr> <66e540fe0605090130r70be830bo40a21ae71b043b5b@mail.gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1147167820 1864 80.91.229.2 (9 May 2006 09:43:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 9 May 2006 09:43:40 +0000 (UTC) Cc: guile-user , Neil Jerram Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue May 09 11:43:37 2006 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FdOkf-0002ij-2u for guile-user@m.gmane.org; Tue, 09 May 2006 11:43:33 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FdOke-0004SI-0F for guile-user@m.gmane.org; Tue, 09 May 2006 05:43:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FdOkZ-0004SB-CV for guile-user@gnu.org; Tue, 09 May 2006 05:43:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FdOkY-0004Ru-I2 for guile-user@gnu.org; Tue, 09 May 2006 05:43:27 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FdOkY-0004Rr-D7 for guile-user@gnu.org; Tue, 09 May 2006 05:43:26 -0400 Original-Received: from [140.93.0.15] (helo=laas.laas.fr) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FdOla-0002xa-1Q for guile-user@gnu.org; Tue, 09 May 2006 05:44:30 -0400 Original-Received: by laas.laas.fr (8.13.6/8.13.4) with SMTP id k499hLXj017019; Tue, 9 May 2006 11:43:24 +0200 (CEST) Original-To: djurfeldt@nada.kth.se X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 20 =?iso-8859-1?Q?Flor=E9al?= an 214 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: powerpc-unknown-linux-gnu Mail-Followup-To: djurfeldt@nada.kth.se, guile-user , "Neil Jerram" In-Reply-To: <66e540fe0605090130r70be830bo40a21ae71b043b5b@mail.gmail.com> (Mikael Djurfeldt's message of "Tue, 9 May 2006 10:30:10 +0200") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang at CNRS-LAAS X-MIME-Autoconverted: from 8bit to quoted-printable by laas.laas.fr id k499hLXj017019 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:5298 Archived-At: Hi, "Mikael Djurfeldt" writes: > On 5/9/06, Ludovic Court=E8s wrote: >> And thus the first `define-method' creates a new, empty, generic >> function. That makes it sometimes quite tricky to spread method >> definitions all over the place (e.g., see G-Wrap...). > > Could you elaborate on that? In what way does GOOPS/module system > make this tricky, and how do you envision a better design? Oh, I do not mean that GOOPS and Guile's module system make GOOPS hard to use --- and I'd be unable to envision a better design. I think they're both good at their job. Rather, my opinion is that CLOS-like systems are so flexible that it can make it quite hard to understand the structure of a piece of code, specifically when method definitions are spread across different modules. This is what happens in the GOOPS-based G-Wrap. A set of classes and generics are defined in some top-level module. Then, there are various modules that add two-line methods to these generics. Since there's a relatively deep class hierarchy, understanding what the control flow may be can be quite hard, especially in the presence of `next-method' calls ("vertical code reuse", which I find problematic --- but this is not CLOS-specific). Interestingly, in G-Wrap, some modules specialize methods to classes that are not exported themselves. Nothing wrong with that, but again, it doesn't help the reader. Also, the fact that method dispatching takes all arguments into account, as well as the number of arguments, is one of CLOS' strength compared to static OO languages like Java/C++. But it also makes it harder to guess what code will be executed by just looking at a given method call. As a method-overloading-module author, one must make sure to: 1. Not export the binding in question (as shown with this thread); 2. Import the module that actually defines the generic; 3. Correctly spell the generic's name. Of course, these are all necessary for ordinary procedures as well. But in the case of GOOPS methods, these can yield harder-to-find errors (see, e.g., http://lists.nongnu.org/archive/html/g-wrap-dev/2005-09/msg00000.html ). Furthermore, CLOS-like systems introduce a new class of side-effects that has to be taken into account by the user. Usually, the only side-effect induced by using a module is that it modifies the user's name space. When GOOPS method definitions are spread across modules, one must be aware that using a module means more than just adding bindings to their name space. For instance, one may have to use a module even if none of the bindings it exports is of interest, just because that module adds methods to various previously-defined generics. Understanding that kind of relationship among modules is not trivial when reading a harmless-looking list of `use-module' clauses, IMO. Another way to express all that it that CLOS is very name-centric. This makes a significant difference compared to the Scheme philosophy where names (top-level bindings) can often be avoided by passing procedures/closures around. > Rather, I think the points where it can be criticized is that some > things are a bit "too automatic" and there should be better and more > error messages in some cases. Right, it is true that it's a bit "too automatic". OTOH, automatic features like automatically creating when the first `define-method' for a given name is encountered are quite handy. As for error messages, I'm not sure they could really be improved. In fact, issues like those I mentioned above are "normal", i.e., they are not GOOPS' nor the module system's fault: rather, these are traps users should pay attention to. ;-) > Of course, one may feel that the fact that methods can "spread" > through the generic function in a rather arbitrary manner across > module borders is a problem. For those who want a more restricted > access to methods, there is the possibility to use extended > generics. This is explained in NEWS, I think. I couldn't find information about it. Do you have more specific pointers? In fact, I had been very enthusiast about CLOS in general and GOOPS in particular for some time. Now, I no longer find it so cool, notably because of the readability issues I mentioned earlier. I also tend to agree with the arguments in http://paulgraham.com/noop.html and related pages. Thanks, Ludovic. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user