RE: Is OO a deliberate fraud?

["Ruth Ivimey-Cook" <Ruth.Ivimey-Cook@xxxxxxxxxx>]

Larry and others,

Larry wrote:
> 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

Thanks :-)  I have thought for a while that the notion of Class wasn't
totally inappropriate, even when you have cheap processes. My recent
experiences have been instructive in explaining where a split might usefully
lie...

> "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.

Basically, yes. Within that limited domain, you have all the bells and
whistles of OO - abstracts, virtual types, constructors, etc. 
 
> 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

The side-effect free stuff is all very well, but it can lead to very
cluttered code and also, potentially, very inefficient code. In can make it
hard to maintain. I don't have a magic bullet here, but I am not one of
those who think all methods / procs should be side effect free "on
principle"; rather, any side effects should be clear and apparent to the
reader in some way. Being able to throw a number of references into a "bag"
and keep a handle on the "bag" is one option, but such bags should be able
to maintain both "resource references" as well as channel ends safely. [3]

> 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'm game, yes :-)   Finding a solution to the "wiring up" issue - even if
it's simply by using a GUI that codes things for you - would certainly be
high on my list of wishes for a new environment. Perhaps Gerald H's work
would be useful here?

> 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".

My split was more pragmatic than idealistic; that said, it does work (but in
my current experience, only when you have OO reference types as well as
value types to play with), or you end up with some awful inefficiencies
which preclude its use at all.

Regards,

Ruth

[3] What if your Draw code is drawing to memory directly - no drawing
process required. Must we maintain value-copies of the bitmaps? References
to memory? How about pen colour, etc?  Some of these things are obviously
value types but some might seem to be value types until the hardware appears
and you suddenly need a reference to an external resource...  Do we end up
saying you _have_ to encapsulate in a process? That seems bad to me; an
excuse for programmers to say "its no good, I can't do X"