On 2016-03-30 22:57:25 +0300, Marko Rauhamaa wrote: > Panicz Maciej Godek <godek.mac...@gmail.com>: > >> 2016-03-30 19:53 GMT+02:00 Marko Rauhamaa <ma...@pacujo.net>: >> 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
