From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Marko Rauhamaa Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Re: anyone define port types? Date: Thu, 31 Mar 2016 22:28:01 +0300 Message-ID: <87y48ysb0e.fsf@elektro.pacujo.net> References: <87y492mnjp.fsf@pobox.com> <87io046wp7.fsf@drakenvlieg.flower> <87a8lfx37i.fsf@elektro.pacujo.net> <87zitfvivu.fsf@elektro.pacujo.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1459452503 25524 80.91.229.3 (31 Mar 2016 19:28:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Mar 2016 19:28:23 +0000 (UTC) Cc: guile-user@gnu.org, guile-devel@gnu.org To: Barry Fishman Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Mar 31 21:28:22 2016 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 1aliGR-0005CU-09 for guile-devel@m.gmane.org; Thu, 31 Mar 2016 21:28:19 +0200 Original-Received: from localhost ([::1]:34034 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aliGQ-0000MG-8w for guile-devel@m.gmane.org; Thu, 31 Mar 2016 15:28:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41839) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aliGH-0000IC-FO for guile-devel@gnu.org; Thu, 31 Mar 2016 15:28:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aliGG-0005Kd-Ej for guile-devel@gnu.org; Thu, 31 Mar 2016 15:28:09 -0400 Original-Received: from [2001:1bc8:1a0:5384:7a2b:cbff:fe9f:e508] (port=45550 helo=pacujo.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aliGE-0005Jn-0H; Thu, 31 Mar 2016 15:28:06 -0400 Original-Received: from elektro.pacujo.net (192.168.1.200) by elektro.pacujo.net; Thu, 31 Mar 2016 22:28:01 +0300 Original-Received: by elektro.pacujo.net (sSMTP sendmail emulation); Thu, 31 Mar 2016 22:28:01 +0300 In-Reply-To: (Barry Fishman's message of "Thu, 31 Mar 2016 12:11:08 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2001:1bc8:1a0:5384:7a2b:cbff:fe9f:e508 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:18265 gmane.lisp.guile.user:12539 Archived-At: Barry Fishman : > On 2016-03-30 22:57:25 +0300, Marko Rauhamaa wrote: >> All you can serialize is information. Objects are living things we >> experience through interactions alone. > > Do we really want our computers to behave like organic black boxes? I'll say yes. > In Guile you can export, at the module level, what interface you like > and hide any raw "get-x" style assessors. You mean GOOPS. Guile can do a lot better. > True you can get at raw state through the slot interface, but Guile is > built around observably, not security, and you could get at the > contents of closures if you really wanted to. I don't care about security. I care about the approach. To me, objects are thingies that interact with their surroundings. GOOPS' model is the opposite: objects are conceptually mere dead records, structs. > The fact that objects represent state doe not force the > exact implementation of that state be considered outside of a single > module. The accessor (get-x) evokes the idea that there's a piece of information guarded by the object that the object is willing to divulge through the accessor, however implicitly that piece of information is encoded internally. I don't usually think of objects as containing information. I don't like Java's and Python's properties because they also make objects seem like records. > Serialization does not have to be lost. You serialize data, you don't serialize objects. You can serialize configuration information. You can serialize messages. You can serialize collected data. But objects exist, live, breathe and interact. > I used to do large scale development in C++. Books like "Design > Patterns" are really just series of hacks to get somewhat around the > fact that objects built around a fixed, rigidly defined set of methods > becomes difficult to adapt and maintain as projects grow over time. I have some development on my belt as well. I don't know what trauma design patterns might have inflicted on you on your career. > I found that Common Lisp's CLOS style way of looking at objects would > have made thing far easier to develop and maintain and produce a more > stable code base. I really got to dislike C++'s and Java's object > model. So you haven't personally experienced the blessings of CLOS? > I don't mean this to be construed as trying to make Guile a purely > functional language. I like choices. GOOPS is the antithesis of functional programming, I think. >> You mean you can't associate new methods to an object. That's true >> and can be annoying sometimes. However, GOOPS' cure is worse than the >> disease: it exposes the slots of the object. > > What is exposed or not exposed seems to be something better handled by > what modules export, and not be intrinsic to objects themselves. This > allows methods, defined outside the module, that uses just the module > interface to the object (or several objects) to be easily defined and > somewhat separately manged. This becomes crucial as systems grow and > change. Especially allowing for the idea of multi-methods. External, derived functionality is possible at that level with the classic rigid methods as well. If the external methods depend on the methods the module chooses to expose, you are back with the classic model you are trying to avoid. Marko