Things that OO programming lacks (was: What exactly is the licensing situation with GNAT?)

["G.B." <bauhaus@futureapps.invalid>]

On 14.11.14 14:35, Dmitry A. Kazakov wrote:
>> That's the theory. But in practice, having all the hard stuff written
>> >already just promotes cutting and pasting of a different color. The code
>> >that*uses*  those classes is normally not reusable. That's what is cutting
>> >and pasting. It's been shoved down a level or two.
> Maybe. But, again, what would be better?

Better? A mode of expressing what we know beyond our objects,
in dedicated language:

Since programmers are starting to know more about patterns
of connecting objects, I suppose something expressing those
patterns more clearly would be useful.
For example, "connections" may refer to order of calls in time,
and to "flow" caused by "data".

A way to express these patterns of OO  programming will avoid
producing intractable state manipulation code (a.k.a. spaghetti).
OO does not prevent programmers from just operating setters
and getters, "knowing" the effects this has on the "other" object.

When a programming method using patterns relies on naming
and conventions, like the GoF patterns do, that's not language,
is it?

Another important example is events.

Consider a system with many inputs, many outputs, and also
some treads. A GUI program, or a control unit, an OS, etc.
There will be events in need of a response.
Events are generated either by programs or by the world.

Then I want to express, at the language level, using
dedicated source text:

-  What are all of the events than can have a normal effect
    on the program?

-  What are the possible orders of these events?

-  How can I arrange for orders of events to be know
    at or after run time?

-  How can I connect events expressly to objects that
    respond to the events?

-  How can I learn, by looking at specific language in
    a program, which objects are connected to an event?

At first, Ada's task type seem to covers order of events,
in bodies (only?). Using the control structure of the
language facilitates expressing possible orders:

   task body ... is
   begin
      ...
      accept first_this;
      ...
      accept then_that (...)
      ...
      loop
       select
         accept either_A (...)
         ...
       or
         accept or_B (...)
         ...
       end select;
      end loop;
   end ;

But this is only half way, since task objects' definition does not,
by design, show possible connections of multiple task objects in
a program.  The other side, that of calling tasks (selectively)
adds to the complexity of analysis.

Similarly, there are ways to place a restriction on the
order of subprogram calls. For example, one might force an order
by having a sequence of functions consume and produce objects
from an ordered sequence of types:

    function A (Obj : T0) return T1:
    function B (Obj : T1) return T2:
    ...
    function M (Obj : T16) return T5:
    ...

Or one could be using condition expressions, like in

   procedure P (Object : in out Typ; ...)
    with
      Pre => Object.State (State_No'(4711));


   function State (Object : in Typ) return State_No;

but both are not specific language, and at least the second,
i.e. Pre referring to object state, require mere conventions.

To me these look like a poor workarounds, Pre more than the types TK,
even when they assist the client programmer writing calls of
subprograms in proper order. Which only shows that a way to
express order, e.g. in interfaces, is valuable.

To have language for expressing connections in a program would
be better.  We only got tools that show graphs of a few arrows,
as in design diagrams for interfaces and models. But we do not
really have source text specifically addressing order of events,
and connections made on the occasion.