From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Barry Fishman Newsgroups: gmane.lisp.guile.user Subject: Re: GOOPS constructors Date: Wed, 23 Jul 2014 11:02:58 -0400 Message-ID: References: <87d2cxoadc.fsf@elektro.pacujo.net> <877g35o89c.fsf@elektro.pacujo.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1406130647 20928 80.91.229.3 (23 Jul 2014 15:50:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Jul 2014 15:50:47 +0000 (UTC) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Jul 23 17:50:40 2014 Return-path: Envelope-to: guile-user@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 1X9yoS-0001P4-7q for guile-user@m.gmane.org; Wed, 23 Jul 2014 17:50:40 +0200 Original-Received: from localhost ([::1]:45754 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X9yoR-0003XI-SE for guile-user@m.gmane.org; Wed, 23 Jul 2014 11:50:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X9yo0-0003WB-AJ for guile-user@gnu.org; Wed, 23 Jul 2014 11:50:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X9ynt-00050S-L7 for guile-user@gnu.org; Wed, 23 Jul 2014 11:50:12 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:37732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X9ynt-0004x0-C0 for guile-user@gnu.org; Wed, 23 Jul 2014 11:50:05 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1X9yns-0000no-49 for guile-user@gnu.org; Wed, 23 Jul 2014 17:50:04 +0200 Original-Received: from fl-71-52-208-159.dhcp.embarqhsd.net ([71.52.208.159]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Jul 2014 17:50:04 +0200 Original-Received: from barry_fishman by fl-71-52-208-159.dhcp.embarqhsd.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Jul 2014 17:50:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 103 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: fl-71-52-208-159.dhcp.embarqhsd.net Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAALVBMVEXG87t8xXThBQWq85q9 87AvUC6PUVH/BgamyajC87a/87P////r6+ud7oq49KsBy7dJAAACKUlEQVQ4jc3Sv2vbQBQH 8CulwcEdeoOKwM1QD/bSzVktKDEdMpRqeMKQFNqAhEGbh3aVB5sDafAYL106xZMzuAiehnqI EciLMR2viz0Vor+hdydZMa6z97sI9NH7cYdI9ZGQr4/kP4Fu1akehFqHDaoHoOviPLD3oVtz 7PIErFCeeRdqOuvptwDMYSyfpKB7iYh3DOCTeOKzegGvk8hD1O22eD2B9tUWum9wbpXYy6NA wAzMeQFu1AeT2VAW0Af4sYUvfmRbCWLciXq0B2ZYf4C+GL/AGBIcOP4O4MzFKbiTAGOPYg7V mu1j5OIdfIgT7FtHGKoZIHKB6IuK9kDODpNsK0pPVnqCFbyFSyYWMMPnIA9CVsbm5l2HuRjZ FVERBXFPs8QQMhIZvqUX8jJmiTzIRy5FwWhEdAmR4y1KnQbn1KrnMOrLj6PPDnW8bw2+1K7I OINrecF9jwyJyBlfAvkzvlEy6DBHJ3m+8yU5HY9V0TWl+nALx+slMQTkRWKHQprEOJeST3qg p8RoHZRjsmm1ctrrJ0HkX0mFvG+uTnf7qe3SNG2dcc4bm70iAemaHxAJ91zF2G2noMl/UVVk bAoihgINlKwa6XkuhBsKGJgnPBuVEeG/5Wzqz3tZ0bYh4SsBS+qXZtTMRTWUcC/Bnybi7+R5 VoaAdZNz7ZU/RT8u2nEuQTw0VpmjH/7UChHQlFAGT1Rg8GS7Hcm+0F4EDgvYIohLAFS++wvs R0Pau3fdJgAAAABJRU5ErkJggg== User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3.92 (gnu/linux) Cancel-Lock: sha1:vpQ6JnaWiCpVfatLcpYtRXuBc38= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:11356 Archived-At: On 2014-07-22 16:03:43 +0300, Marko Rauhamaa wrote: > Tobias Brandt : > Well, I was trying to find a simple toy example to demonstrate the need, > but maybe I'll need to find a more compelling one. > > How about: > > ======================================================================== > (define-class () > (msg #:getter msg #:init-keyword #:msg)) > > (define-class () > (path #:getter path #:init-keyword #:path) > (code #:getter code #:init-keyword #:code) > (fs #:getter fs #:init-keyword #:fs)) > > (define-method (initialize (@ ) args) > (let-keywords > args #f ((path #f) (code #f) (fs #f)) > (next-method @ (list #:msg (format #f "File error in ~S (~S)" path code))))) > ======================================================================== > > How do I now write the getters for path, code and fs? If you need to redefine "initialize" to do what you want, this is a clear indication that you might using the wrong abstraction. You are trying to force methods to be a part of the class definition. They don't belong there. Although this is done in other object oriented languages, this it not a part of CLOS/GOOPS. In GOOPS, methods and data are distinct. Classes form a hierarchy of the types of objects. Methods provide an common interface for a collection of object types. Languages like Java recognize the distinction, but still force everything (including independent functions) into classes. You can build your class tree to include , , etc. You can add methods for area, circumference, etc. You can make your code a package for others to share, or buy. If I then come along and use your package in a application. I might want to draw out the shapes. My draw methods might be GTK specific. Where does my code belong? You may not want to update your package to include my GTK specific draw functions. In other languages, if I have your source, I can patch your package to include my own draw virtual method, I will then have to maintain it and track all your bug fixes and changes. I might build a visitor pattern, if you made that possible, but this does require me to track all your future class structure changes. However in GOOPS, I can build my own draw methods for your derived classes along with any other independent packages that I use. I could restrict my methods to use only the access methods you provide for each of the specific classes I support, and avoid internal class information. I don't need to touch your code. GOOPS will auto-generate simple assessors for you, but anything more complex really should not be pushed into the class definition. After having to use gross mechanisms (like visitor patterns or even #ifdefs) in languages like C++, I find this as a significant improvement. If two classes have no common fields, like and , they just share a common interface, they are not derived from each other. They only need a common interface class (like ), if this is required for class inheritance (like being used in higher level method signatures). There is no need to juggle a set of Interface only base classes, and the associated derived classes for a package, each time an application needs a new interface method. Interface classes are just needed for pure class inheritance. Application specific methods can be added without having to modify the class definition in an external package. --8<---------------cut here---------------start------------->8--- (define-class () ) ; No common class fields (define-class () (path #:getter path #:init-keyword #:path) (code #:getter code #:init-keyword #:code) (fs #:getter fs #:init-keyword #:fs)) (define-method (get-message (err )) (format #f "File error in ~S (~S)" (path err) (code err))) --8<---------------cut here---------------end--------------->8--- You don't get any "missing method" until run-time, but Scheme is a dynamic language, so this isn't generally true anyway. You gain the ability to make error messages unique in each of several applications that share common error throwing code. (define-method (my-message (err )) (format #f "ERROR: Code ~S in ~S" (code err) (path err))) (define-method (my-message (err )) (format #f "ERROR: Unknown error type ~S" err)) -- Barry Fishman