RE: Objects, processes, and encapsulation

["P.H.Welch" <P.H.Welch@xxxxxxxxx>]

Hi Andrzej,

> > They have made serial programming hard indeed.  We have to view each
> > collection of object methods as invocable with arbitrary interleaving ...
> > with that interleaving happening both between the various invocations and
> > in the middle of them (with external method calls marking interleaving
> > points - call backs)!  That's what makes OO hard and systems unscalable.
> 
> Where such an opinion comes from? I have participated in developing rather
> large (aprox. a million LOC) commercial systems using OO technology.
> OO technology was neither "hard" nor resulted in "unscalable systems".
> Actually, I cannot imagine such effort without using OO technology.

The first and last sentences of my paragraph quoted are opinions.  The middle
sentence is fact.  Good OO designers/programmers are aware of this and take
care not to fall into the semantic unknown that callbacks allow ... so that:

  setX (42);         -- i.e. x = 42, where x is a private attribute
  thing.foo ();

following the above code, they are entitled to believe that x is still 42.
But to do this, they must retain control both of the object whose code above
is being executed *and* the environment in which it lives (in particular,
what thing.foo does, not forgetting what everything with which thing.foo
engages also does).  The code will not be reusable outside that control.

With good awareness and design, the scope of the environment that has to be
controlled can be limited.  But OO languages do nothing to limit that scope
and it can easily expand to the whole system - and, then, there is a limit
to the complexity of systems that can be managed.

But many OO designers want those call-backs.  It would help if OO languages
enabled us to specify whether method calls updated state or merely computed
information from it.  The latter type are safe to allow in call-backs - the
former lead to the above semantic unknowns.  But good OO designers know
this and don't do the former.  But they get no help from their languages
and that's a huge failing.  You have to be "good" to do OO and that's not
right ... ideas/languages should enforce good behaviour ... I can't be good
all the time!

And even if we fixed OO languages to sort out those call-back semantic
black holes, why settle for an object model that can't control the way
it is used (i.e. passively allowing the arbitrary interleaving of its
methods)?  Sometimes that's the model we want, but often it ain't.

A process model is simply an object model that allows us to specify as much
(or as little) control as we like over how it engages with its environment.
It's much more powerful and (arguably) more natural.  And CSP gives us
an algebra for formally specifying properties of those interactions and
verifying that implementations meet them.  And we don't have those callback
problems ... local analysis of process code is sufficient ... the semantics
compose when processes are put together.  This stuff does scale.

But the world is wedded to OO and demands ever larger and complex systems.
When did you last notice strange behaviour from Windows ... some unexpected
side-effect between apparently unrelated applications ... tiresome differences
in behaviour between (object) code running in one environment and another?
When did you last have to reboot your PC or set-top box?  And are things
getting better or worse?  I know what I feel ...

Cheers,

Peter.