[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Objects, processes, and encapsulation
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
>> When I proposed integrating the (client-server) design rule into a
>> 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.
Dr. Ian Robert East
Room T2.10, Turing Building 0 (44) 1865 484529
School of Computing and Mathematical Sciences
Oxford Brookes University
Oxford OX33 1HX ireast@xxxxxxxxxxxxx
2001/2 Term 1 Consultation hours: