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: Wed, 30 Mar 2016 22:57:25 +0300 Message-ID: <87zitfvivu.fsf@elektro.pacujo.net> References: <87y492mnjp.fsf@pobox.com> <87io046wp7.fsf@drakenvlieg.flower> <87a8lfx37i.fsf@elektro.pacujo.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1459367862 14649 80.91.229.3 (30 Mar 2016 19:57:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Mar 2016 19:57:42 +0000 (UTC) Cc: Andy Wingo , "guile-user@gnu.org" , guile-devel To: Panicz Maciej Godek Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 30 21:57:41 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 1alMFE-0004G8-Hk for guile-devel@m.gmane.org; Wed, 30 Mar 2016 21:57:36 +0200 Original-Received: from localhost ([::1]:56535 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alMFD-00006O-8b for guile-devel@m.gmane.org; Wed, 30 Mar 2016 15:57:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41342) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alMFA-0008Vn-Bi for guile-devel@gnu.org; Wed, 30 Mar 2016 15:57:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1alMF9-0001PZ-ES for guile-devel@gnu.org; Wed, 30 Mar 2016 15:57:32 -0400 Original-Received: from [2001:1bc8:1a0:5384:7a2b:cbff:fe9f:e508] (port=36648 helo=pacujo.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alMF5-0001Ox-Ts; Wed, 30 Mar 2016 15:57:28 -0400 Original-Received: from elektro.pacujo.net (192.168.1.200) by elektro.pacujo.net; Wed, 30 Mar 2016 22:57:25 +0300 Original-Received: by elektro.pacujo.net (sSMTP sendmail emulation); Wed, 30 Mar 2016 22:57:25 +0300 In-Reply-To: (Panicz Maciej Godek's message of "Wed, 30 Mar 2016 21:02:22 +0200") 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:18258 gmane.lisp.guile.user:12532 Archived-At: Panicz Maciej Godek : > 2016-03-30 19:53 GMT+02:00 Marko Rauhamaa : > The problem with closures is, among others, that they are > non-serializable What is there to serialize in objects? How do you serialize a car? How do you serialize an ant? How do you serialize a person? All you can serialize is information. Objects are living things we experience through interactions alone. And yet, UNIX knows how to suspend a process. Virtualization technologies are very good at snapshotting live virtual machines. Tricky business but the results are quite impressive albeit not fully flawless. >> * You don't need classes for OOP. You only need objects. > > JavaScript made a similar assumption, which -- I believe -- turned out > cumbersome, because I sometimes have to pretend that it has classes > despite that it doesn't. I can't speak for JavaScript. Point is, you should only care about interfacing the objects, not about their pedigree. >> * Don't expose the internal state of objects. Only interact with the >> object through methods. > > I think it is a good rule, but it's better if you can do without > state. Stateless objects are dead as stone. However you present it, statefulness is the core of objects. > I believe that methods *are* external to objects. Linguistically, you > don't "button.press()"; you "press(button)". I won't debate linguistics. I can only say the methods-of-objects is a very convenient paradigm that helps me organize practical programs. > I also think that tying methods to objects is one of the problems of > OOP, because the designer of an object has to know in advance which > actions on an object are conceivable. 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. Marko