From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 109fba,7f8fc37d854731d6
X-Google-Attributes: gid109fba,public
X-Google-Thread: 103376,7f8fc37d854731d6
X-Google-Attributes: gid103376,public
X-Google-Thread: 1108a1,7f8fc37d854731d6
X-Google-Attributes: gid1108a1,public
X-Google-Thread: 10461e,7f8fc37d854731d6
X-Google-Attributes: gid10461e,public
X-Google-Thread: 114809,7f8fc37d854731d6
X-Google-Attributes: gid114809,public
From: drs <drs@inxpress.net>
Subject: Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE
 tools)
Date: 1996/11/10
Message-ID: <3286402A.3375@inxpress.net>#1/1
X-Deja-AN: 195691337
references: <32813322.41C6@kyebek3.kjist.ac.kr>
 <55pqr5$136a@grimsel.zurich.ibm.com> <328109CD.6685@concentric.net>
 <vwjpw1pzyue.fsf@osfb.aber.ac.uk>
content-type: text/plain; charset=us-ascii
organization: University of Wisconsin
mime-version: 1.0
newsgroups: 
 comp.object,comp.lang.c++,comp.lang.ada,comp.lang.smalltalk,comp.ai
x-mailer: Mozilla 2.02Gold (Win95; I)
Date: 1996-11-10T00:00:00+00:00
List-Id: <comp.lang.ada>


Piercarlo Grandi wrote:

[C++ prototypes omitted]

>So far this is not an OO program, according to your definition, for
>there are no objects whatsoever in it, only classes, and there are no
>``interactions'' among classes in it either.

This is correct. "classes" are merely prototypes in C++. "Objects" are properly 
instantiations, as far as C++ or smalltalk is concerned.

alovejoy> The architecture and design of a program is a function of what
alovejoy> **objects** it contains and how they interact.

>Now let's try to add some more detail:

  // the above plus ...

  main()
  {
    complex c1, c2;
	//etc.
  }

>Is this an OO program? It's hard for me to see any objects in it either
>for I can only see variables (memory objects, a different concept) and
>they don't interact with each other in any sort of interesting meaning
>of the word.

Well, c1 and c2 are indeed instantiations of the above prototype; they have a 
defined address and can do things (unlike the prototype). You're wrong if you 
think c1 and c2 are not objects; they are. entities of the class complex create 
their own scope, which is internal and allows internal processes. This really is 
quite different from C. Now, if your idea is that "Object-oriented"  boils down to 
message sending, then I think you're correct; but by that definition there are 
only a few true "object-oriented" languages, and C++ is not one of them. 

>Objects do come into existence (thanks to the execution of constructors)
>only during the _execution_ of the program, and they are passed as
>arguments to various procedures at execution time too; they don't seem
>to be contained in the *program*, and even when they are contained in a
>computation created by executing the program they don't seem to
>interact, any more than the arguments to a procedure may be said to
>``interact''.

This is wrong. c1 and c2 are scoped within the whole of main(). This is 
not really different from any globally scoped object in, say, smalltalk.
You could easily cause c1 and c2 to interact, although your example 
does not call for much interaction. Performing an addition of two 
complex numbers is not really much of an "interaction" anyway because
the numbers themselves are probably const. The overloaded + probably
instantiates a new number, and changes nothing in the args. But let's 
suppose class bicycle

class bicycle
{
	Wheel w1, w2;
	Brake b1, b2;
	Frame f1;
	Seat s1;
	Freewheel fw1;
	//etc.
	public:
	
	void ride();
	void slowdown();
	void changegears();
	//more methods for interaction between parts
};

The parts model the whole. If you now instantiate an instance of 
class bicycle, in order of it to do anything, the parts *must* interact.
So the issue of what really is "Object-oriented" turns much more 
on a world-view (a way of concieving a problem, perhaps) than on
any particular feature such as "runtime polymorphism." Setting up a 
bicycle object is *qualitatively* different than doing computations about
riding using C functions. 


Regards,

DRS