Re: Objects, processes, and encapsulation

[p0072370 <ireast@xxxxxxxxxxxxx>]

Tom, Peter

I understand Tom's example, which illustrates several really nasty 
pissabolities in what I like to call "Classic OOP" (CLOOP?) (I save COOP 
for Concurrent OOP.) For example, two objects, each containing the other, 
and having no compile-time knowledge of what a contained object might be 
or do. I was just trying to home in on what encapsulation might mean in 
the light of Meyer's requirement that objects provide multiple services.

Meyer's point, I think remains quite strong. You DO want 'objects' to 
still respond to multiple requests, even if they possess their own 
thread. I'm wondering how one might achieve that and preserve useful 
modularity.

>> When I proposed integrating the (client-server) design rule into a
>> programming 
>> language at CPA '01, the only objection was that it was too restrictive 
>> (and perhaps too prescriptive). Maybe. Then maybe not. I think mostly 
>> such concern comes from confusion with data flow. Only cyclic _services_ 
>> are banned. Cyclic data flow presents no problem.
>But I also want to express I/O-PAR systems.  These also have no problem
>with cyclic data-flows, but have no obvious description as client-server.
>The point of the design is that all processes are equal peers.  Forcing
>their description as client-servers would lead to cyclic services, for
>which there are no deadlock guarantess.  Yet they are deadlock-free.
Do you think there are many requirements you just could not satisfy 
without them? Flip side is whether a big enough range of requirements 
could be met with C/S alone to make tools useful, given the deadlock 
freedom? I'm not sure we can answer this without trying.

Moving from assembler to Pascal/C denies a huge space of useful, and 
correct, programs (including all reactive systems), but it proved very 
valuable, because of the problems it built out.

As I remember, it's possible to safely join a C/S network to an I/O PAR 
one via a single connection. One could perhaps allow for such things 
without complicating a language overmuch. Beyond that, we need another 
Jeremy to look into design rule combination and the consequent language 
issues. PhD project?

I suppose my thinking is that, just maybe, delivering an intuitive 
programming language that allows concurrent programming without deadlock, 
AND without the need for auxiliary uncommon skills (like maths, or using 
specialist tools), would get the whole CPA/CSP thing finally noticed.

Ian


Dr. Ian Robert East

Room T2.10, Turing Building                      0 (44) 1865 484529
School of Computing and Mathematical Sciences
Oxford Brookes University
Wheatley Campus
Oxford OX33 1HX                                ireast@xxxxxxxxxxxxx

2001/2 Term 1 Consultation hours:
Mon 09.00..11.00
Fri 11.00..13.00