RE: Is OO a deliberate fraud?

[tjoccam@xxxxxxxxxxx]

All,

Ruth's non-dogmatic approach would play off very well against the dogmatic
approach of people like me and advance our nascent art, I think...

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

Cluttered, maybe, but I don't see why it has to be inefficient --- the
channel just gets copied into a local variable, surely... And I really
don't even see cluttered. The HOSTIO and STREAMIO code in the occam
toolset never impressed me as cluttered, but it used a global channel of
just the sort I'm thinking of.

> In can make
> it
> hard to maintain.

Were HOSTIO and STREAMIO 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]

That's why I propose resource-passing channels; but I insist on their
being toplevel nested, because that avoids hiddenness and also has the
benefit of making testing easy --- a huge advantage of "occam harness"
over current driver code.

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

To me this split is very idealistic AND pragmatic --- it gets rid of
hiddenness, lays bare all critical code to be testable by toplevel
modules, and in my experience does not necessarily introduce any
significant inefficiency (of course that may require control over compiler
and OS, which may otherwise buffer everything up the wazoo).

>
> 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?

That would be within the scope of programmer judgement. Remember, however,
the disaster of 1980 DOS PC's "just in memory" graphics modes; perhaps it
would be better to conceptually make the graphics target a separate
communicating entity.

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

I hate the "I can't do X" thing, but I believe in forcing it into its
place, i.e. the single wild heritage instead of fragmented virtualized
spaghetti code. I don't think you really have to give up much.

Larry