[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Is OO a deliberate fraud?
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
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".
> Fred wrote:
>> I'm not completely convinced that OO is good for this either -- makes
>> good reasoning about the system's structure, but I've had issues with
>> 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,
> In creating the software for my last contract, I was somewhat constrained
> 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, where it is useful to associate the operations
> possible on a type (or group of types using single inheritance and
> types) with the data. For example, I was manipulating the operations that
> machine can perform on a length of material, and for that situation
> 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 and without the requirements of
> I would have used a more process based approach.
> In short, I think that process based systems do benefit from a degree of
> but (as I currently see it) only where you are defining a new data type
> 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
> 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
> 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.
>  Value types in C# are just like classes but for the fact that values
> always copied, in the same way as integers or doubles.
>  I find JCSP hard going in terms of boilerplate and connecting things
> together, and dearly miss the simplicity of occam's syntax and compiler