Re: anyone define port types?

[Marko Rauhamaa]

Barry Fishman <address@hidden>:

> 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