From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Clinton Ebadi Newsgroups: gmane.lisp.guile.user Subject: Re: SOS: Simple Object System Date: Wed, 24 Sep 2008 14:00:46 -0400 Message-ID: <874p45zanl.fsf@unknownlamer.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1222279292 26355 80.91.229.12 (24 Sep 2008 18:01:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Sep 2008 18:01:32 +0000 (UTC) Cc: guile-user@gnu.org To: "Maciek Godek" Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Sep 24 20:02:29 2008 connect(): Connection refused Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KiYgq-0007GT-W3 for guile-user@m.gmane.org; Wed, 24 Sep 2008 20:02:17 +0200 Original-Received: from localhost ([127.0.0.1]:35530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KiYfo-0000W8-PX for guile-user@m.gmane.org; Wed, 24 Sep 2008 14:01:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KiYfZ-0000W2-JU for guile-user@gnu.org; Wed, 24 Sep 2008 14:00:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KiYfY-0000Ve-CG for guile-user@gnu.org; Wed, 24 Sep 2008 14:00:57 -0400 Original-Received: from [199.232.76.173] (port=55881 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KiYfY-0000VY-5t for guile-user@gnu.org; Wed, 24 Sep 2008 14:00:56 -0400 Original-Received: from deleuze.hcoop.net ([69.90.123.67]:47585) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KiYfX-0006IR-Hc for guile-user@gnu.org; Wed, 24 Sep 2008 14:00:55 -0400 Original-Received: from cpe-071-065-238-103.nc.res.rr.com ([71.65.238.103] helo=localhost.localdomain) by deleuze.hcoop.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KiYfV-0006kO-N6; Wed, 24 Sep 2008 14:00:53 -0400 In-Reply-To: (Maciek Godek's message of "Wed\, 24 Sep 2008 15\:09\:46 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) 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:6812 Archived-At: "Maciek Godek" writes: > The other is that in GOOPS a method is something > different than what is commonly known in OOP, because > a class doesn't know its methods (and furthermore, > methods can be created at any time of program execution, > not only during class definition). I'm not saying that > it's good or bad (but it's quite confusing when a few similar > but different notions share one name) Interestingly enough, CLOS predates C++ and Java ;-) Separating classes and generic functions makes the language more powerful--now two orthogonal concepts may be combined in arbitrary ways. The classic example of having generic functions are multimethods wherein you can dispatch on the type of every argument of the generic. A simple example of this is the (simplified) present method from CLIM: (define-generic present (instance view)) Which then allows you to do nifty things like: (define-method (present (instance ) (view )) (format #t "[~A]" (alt-text-of instance))) (define-method (present (instance ) (view )) (display the image somehow)) etc. Doing this with a single-dispatch system is much less aesthetically pleasing. Note also that multimethods are only one of many advantages to having generic functions--they also enable method combinations and a few other things. Stylistically, they make the OO system integrate cleanly with the rest of the language rather than having its own specialized syntax for method invocation. > There is also another issue concerning the fact that > methods are available in global namespace -- the > performance of the interpreter is always penalized > by the type lookup (obviously, this doesn't have to > be the case if the code is compiled) Type lookup in GOOPS should be very fast--there are a few fairly simple implementation techniques that more or less eliminate the overhead of method dispatch (or at least turn it into a few very low overhead table lookups). /The Art of the Metaobject Protocol/ is a good inexpensive book that gives a decent overview of how to implement a fast CLOS. > But the most important feature of OOP that is missed > in GOOPS (because of global namespace methods) is the lack > of the clean separation of interface and implementation > in the way it's done in java, C# and the like. Actually, CLOS/GOOPS are perhaps the cleanest way to separate interface from implementation. You define a protocol as a set of generic functions and define methods upon them -- with no concern for the actual classes used with the protocol. In this way you can do implementation sharing via class inheritance or something akin to Java interfaces (if I understand them properly; I refuse to use such a language) and implement the protocol for arbitrary classes without having to arbitrarily force them to inherit from unrelated classes. -- Jessie: i stuck the phone antenna up the dogs nose and he ignored me