Path: utzoo!attcan!uunet!wang!wdr From: wdr@wang.com (William Ricker) Newsgroups: comp.software-eng Subject: Re: OOP and estimating (OOD v. OOPL v. Synchronicity) Message-ID: Date: 3 Jul 90 02:38:10 GMT References: <25062@mimsy.umd.edu> <5253@stpstn.UUCP> <31116@cup.portal.com> <26855613.749b@petunia.CalPoly.EDU> <3169@stl.stc.co.uk> Organization: Wang Labs, Lowell MA, USA Lines: 66 tom@stl.stc.co.uk (Tom Thomson) writes: >In article <26855613.749b@petunia.CalPoly.EDU> [John R. Dudeck] writes: >> >>A lot of what is gained in OOD is in the de-sequentializing of our problems. ^^^ >Every OO language I have seen makes this claim. However, every OO language ^^^^^^^^^^^ >that I've seen (with one experimental exception, a laboratory toy language) >insists that the messages are SYNCHRONOUS, that the channels between the >processes are UNBUFFERED (and blocking), that every message has a REPLY Who said OOD (Object Oriented Design) was limited to the design of one program? I'd rather use OOD to design a system using asynchronous messages between programs than any "functionally decomposed" SASD method. Yes, Asynchronous tasks are good models for many objects, and OOPLs will not be fully mature until the OOPLs supply this support naturally. We used a synchronous OOPL with an ansyncrhonous operating system to implement a system-level object that would respond asynchronously. We used old objective-C (3.3) on early beta OS/2 LanManager! and it worked. >Claiming OOD provides a lot of gain in de-sequentialising our problems is >pure bunkum. Confusing OOD & OOPL is confusion. OOD is a nice way to design asynchronous systems. Claiming C++ is a suitable OOPL to make use of non-sequential designs is bunkum. Claiming many OOPLs are desequentialized by nature is bunkum. But OO, like functional, does not require a sequential model, it's just [easier to start] implementing that way. <> I would be much less surprised to hear of a parallelizing C++ compiler than a parallelizing C compiler. [I won't try to start a feud on wether C++ (or Ada-- as a friend calls it) is enough OOP for anything, but it's a good Lint, which is more than can be said for any pre-ANSI C.] What was the one lab-toy OOPL that you tought was not sequential? By the way, this debate on sequential/synchronous v. Asynch probably needs to be discussed relative to Brad Cox's (oh oh, grab asbestos, he's invoked a NAME of DOOM) different scales of OO Integration -- IF OOSA and OOD are discussing the interfaces of whole subsystems or programs rather than C++ classes or methods (as I think Brad would say and I'd agree with) THEN It is natural that at these higher levels of abstraction the OO glue is thought of, and should probably be implemented as, Asynch/nonblocking. And At finer levels of detail, it is natural to transition to Syncrhonous/ blocking semantics. (If this is below the HW/SW transition in your favorite system, why lucky you! for the rest of us, we've got to make it happen.) Thus, At some level of integration, there must be a tool that maps between the Asynchronous messages of one to the synchronous RPCs of the other & viceversa. This may be an operating system with Sockets, Pipes, Messages; or a spiffy linker, or an thing we'd call a programming language. Cheeers, Bill -- /bill ricker/ wdr@wang.com a/k/a wricker@northeastern.edu *** Warning: This account not authorized to express opinions ***