RE: Is OO a deliberate fraud?

[tjoccam@xxxxxxxxxxx]

Ruth and all,

I think Ruth's notions are an excellent foundation for building a ladder
out of our hole (even if by Eric Verhulst's standards they may be a little
"politcally correct"). What I'm hearing (correct me if I'm wrong, Ruth) is
to restrict OO to structures and SIDE-EFFECT-FREE operations upon these
structures --- pure, single-tasking, single-processor algorithmic stuff.

Note, however, that "DrawTo" in the Point example appears to require
output to a screen or pen: I would suggest that an outermost nested
channel formal is a requirement to avoid the baneful OO hiddenness. That
might help with Ruth's footnote (2). If you are interested, Ruth, I can
send you a copy of my white paper that deals somewhat with these issues;
it certainly proposes a totally simple harness controlling everything. The
outermost nested channels (called "connectors") are critical to the
design.

I haven't tried to publish my white paper because it's immature (i.e. I
haven't had a chance to create a working model). I think "a distinct split
between process wrappers (using JCSP) and the code within them (C# without
JCSP)" is exactly the right idea, with an emphasis on the "within".

Larry Dickson

> Folks,
>
> Fred wrote:
>> I'm not completely convinced that OO is good for this either -- makes
>> for
>> good reasoning about the system's structure, but I've had issues with
>> this
>> sort of thing and C++ in the past (Java suffers a bit less here).  Won't
>> bore you with the detail here; for the curious,
>> http://frmb.org/rapp.html
>
> In creating the software for my last contract, I was somewhat constrained
> by
> the need to write code that was maintainable by others not versed in CSP,
> and so used a distinct split between process wrappers (using JCSP) and the
> code within them (C# without JCSP), the goal being that understanding JCSP
> was not required unless you were changing JCSP things.
>
> I did, however, very much appreciate the use of proper OO stuff for what
> .NET terms value types[1], where it is useful to associate the operations
> possible on a type (or group of types using single inheritance and
> abstract
> types) with the data. For example, I was manipulating the operations that
> a
> machine can perform on a length of material, and for that situation
> setting
> up a class hierarchy that did that resulted in a very nice, clean and easy
> structure. Other aspects of the OO paradigm didn't work so well, and in a
> more CSP-aware language[2] and without the requirements of
> maintainability,
> I would have used a more process based approach.
>
> In short, I think that process based systems do benefit from a degree of
> OO,
> but (as I currently see it) only where you are defining a new data type
> and
> the operations that are performed on it.
>
> One other thing I have come to appreciate is the integration of collection
> types into the CLR and languages. Although collections are generally
> implemented as reference types there is a lot of compiler and language
> support that makes the contents nearly invisible. In occam terms this
> would
> be a bit like saying:
>
> DATA TYPE Point
>   INT x:
>   INT y:
> :
>
> PROC draw.points([] Point plist)
>   SEQ Point p IN plist
>     DrawTo(p[x], p[y])
> :
>
> PROC draw.points.reversed([] Point plist)
>   SEQ Point p IN plist.Reversed()
>     DrawTo(p[x], p[y])
> :
>
> But in .NET you can define collections in several ways, including the use
> of
> generics (polymorphism done well), have collections that have several
> alternative orderings or with filters, and so on; much more powerful than
> I've seen elsewhere.
>
> Regards,
>
> Ruth
>
> [1] Value types in C# are just like classes but for the fact that values
> are
> always copied, in the same way as integers or doubles.
>
> [2] I find JCSP hard going in terms of boilerplate and connecting things
> together, and dearly miss the simplicity of occam's syntax and compiler
> checks!
>
>
>