Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!shelby!polya!Neon.Stanford.EDU!pallas
From: pallas@Neon.Stanford.EDU (Joe Pallas)
Newsgroups: comp.object
Subject: Re: Information Request on Object-Oriented Testing
Message-ID: <12414@polya.Stanford.EDU>
Date: 12 Oct 89 22:48:21 GMT
References: <25704@santra.UUCP> <601@ajpo.sei.cmu.edu>
Sender: USENET News System <news@Polya.Stanford.EDU>
Lines: 24

In article <601@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward
Berard) writes:

>	3. Since object-oriented systems are naturally concurrent (at
>	   least conceptually), you have all the problems of testing
>	   concurrent software, e.g., non-determinism. 

I disagree: object-orientedness and concurrency are orthogonal.  It
may be natural in some cases to make the object the unit of
concurrency (as in pure Actor systems), but that need not be the case.
Many object-oriented systems have no concurrency in them at all, and
many have a traditional process/task/thread (pick your favorite name)
model of concurrency.

Don't make object-oriented programming harder than it needs to be: if
your system has no concurrency, then you don't have to worry about
concurrency just because you're using object-oriented programming
techniques or languages.

On the other hand, if your system does have concurrency,
object-oriented techniques MAY help to deal with it.  Or maybe
not---this is still open, I'd say.

joe