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,gmane.lisp.guile.devel Subject: Re: anyone define port types? Date: Thu, 31 Mar 2016 12:11:08 -0400 Message-ID: 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 1459440938 30630 80.91.229.3 (31 Mar 2016 16:15:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Mar 2016 16:15:38 +0000 (UTC) Cc: guile-devel@gnu.org To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Mar 31 18:15:30 2016 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 1alfFn-0003bN-Nq for guile-user@m.gmane.org; Thu, 31 Mar 2016 18:15:27 +0200 Original-Received: from localhost ([::1]:33229 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alfFn-0005OV-0a for guile-user@m.gmane.org; Thu, 31 Mar 2016 12:15:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alfFb-0005Mp-Q9 for guile-user@gnu.org; Thu, 31 Mar 2016 12:15:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1alfFX-0002V1-E5 for guile-user@gnu.org; Thu, 31 Mar 2016 12:15:15 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:44014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alfFX-0002S1-3u for guile-user@gnu.org; Thu, 31 Mar 2016 12:15:11 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1alfFQ-0003PO-Hr for guile-user@gnu.org; Thu, 31 Mar 2016 18:15:04 +0200 Original-Received: from fl-71-48-237-75.dhcp.embarqhsd.net ([71.48.237.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 31 Mar 2016 18:15:04 +0200 Original-Received: from barry by fl-71-48-237-75.dhcp.embarqhsd.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 31 Mar 2016 18:15:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 95 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: fl-71-48-237-75.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.130016 (Ma Gnus v0.16) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:EPRDexphOzEVdbsdZ30RjTdwafI= 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:12538 gmane.lisp.guile.devel:18264 Archived-At: On 2016-03-30 22:57:25 +0300, Marko Rauhamaa wrote: > 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. Do we really want our computers to behave like organic black boxes? I think is is more limiting to look at Objects as organic entities rather than encapsulation of state. If objects are state they can be recorded. When your bank account balance looks wrong its good to be able to replay transactions to find out what you are missing. When transactions are happening across a network its nice to be able to restart them rather deal with lost transactions or single points of failure. Yes, Objects can produce their own logs, but this becomes more code to debug rather than a better debugging tool. And the act of building such an interface, really establishes them as state. It is nice to think about the fact that a single implementation of that state is not required by a design, or that it can be changed with little impact on the rest of the system. But such implementation flexibility is not dependent on a "methods within object" type of object construction. It is more a matter of what is exported at the module level. In Guile you can export, at the module level, what interface you like and hide any raw "get-x" style assessors. 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. The fact that objects represent state doe not force the exact implementation of that state be considered outside of a single module. > 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. And a crude way to try to deal with this. Serialization does not have to be lost. 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 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. With distributed environments and the more functional way of looking at things that are possible in Scheme, I think we would better off allowing for extending objects by treating them as immutable state and using monads to perform actions, rather than just allowing for mutable objects and methods. Monads don't constrain object state implementation either. I don't mean this to be construed as trying to make Guile a purely functional language. I like choices. >> 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. 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. One of the security issues with Apple's Objective C is that object methods are always available, if you know about them. Closure based interfaces do make hiding of state easier, but I think localizing all method code in one place makes complex large systems more difficult to maintain. Of course at the true security level, both can be hacked. We are dealing more with what developers might presume about an interface rather a malicious act. Although Scheme itself is not the usual place to think about complex systems, I think Guile does, given what is currently being implemented. -- Barry Fishman