Re: Things that OO programming lacks

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 18 Nov 2014 19:50:23 +0100, G.B. wrote:

> On 18.11.14 14:42, Dmitry A. Kazakov wrote:
>> That is not a language term, so far. And unlikely it would.
> 
> But OO is still lacking such terms, right?

No. You didn't presented any. If you did, you should also show why it would
be impossible or difficult to express the thing as an object, operation
etc.

>> Relation is a logical term.
> 
> Which is why I preferred relationship, which is more open
> to new interpretation.

I don't see which relationships between specifically objects were useful
while incomputable. Some relationships are non-terms on purpose, some are
computable but undesirable (e.g. Unchecked_Conversion stuff). So you should
also show usefulness and preservation of abstraction.

>>> But since for the reasons you named (when mentioning Post-Turing)
>>> we shy way from Boolean valued operations for everything, why not invent
>>> something that expresses what programmers need to known in order to make
>>> those answers?
>>
>> To which questions?
> 
> To those listed so far. Variations of things, tiny or not:
> 
> "Why did the effect of Obj_1's doings occur before those of Obj_2's?

What is effect of an object? It is breaking abstraction at least. All
effect of an object is in its state. That is the fundamental principle of
OO decomposition.

> (Some say, I think, that event aware object oriented systems
> are (worth) a new paradigm waiting to be formalized for the
> very reason that those FSMs and global variables are nasty,
> be they dressed as OO or not.)

Why event is not a primitive operation or not an object?

>> I suppose you are confusing relationships between objects with
>> relationships between types and correctness statements.
> 
> I don't think that time is involved in a relationship between
> types in general, or can I express that relationship in Ada OO types?

Why should you? Time aspects are almost never functional and thus do not
belong to types.

> There are cases where in Ada I can approximate order of types
> in time, so to speak, thanks to nesting:
> 
>    procedure Stage_0 is
>       type T is ...;
>    begin ...
>    end Stage_0;
> 
>    procedure Stage_1 is
>       type T is ...;
>    begin ...
>    end Stage_1;
> begin
>    Stage_0;
>    Stage_1;
> 
> Due to the order of calls, it is now fairly certain that objects
> of type Stage_0.T all exist and "cease to exist" before any object
> of type Stage_1.T starts to exist.
> Is this conclusion(!) perfection of expressiveness already?

I see. You are confusing correctness with the language. In procedural and
OO decomposition when anybody chooses to factor out two procedures like
Stage_0 and Stage_1 these are designed independent. This is again a
fundamental design principle of minimal coupling.

If the client of these entities, carefully observe, this is a third party,
needs to call them in a certain order, that must follow from the
pre-conditions and post-conditions of these procedures. This is what makes

   Stage_1
   Stage_0

incorrect and

   Stage_0
   Stage_1

correct. Under other circumstances the conditions might evaluate
differently making other orders correct. If you don't like this you should
use different decomposition, not procedural or OO. Which is the point. The
paradigm goes first.

> I suppose I'm thinking merely in term of objects, not just OO-ish,
> but just objects that have identity, and any property, shared or
> emerging, that is derived from the formal properties of the objects,
> the program, as well as from the interpretation of (non-OO-)objects
> discussed by the people involved.

No idea what this means.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de