Re: anyone define port types?

[Barry Fishman <barry@ecubist.org>]

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