Re: anyone define port types?

[Marko Rauhamaa <marko@pacujo.net>]

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.

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