Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!think.com!paperboy!hsdndev!husc6!genrad!dxb
From: dxb@genrad.com (Daniel A. Burkhard)
Newsgroups: comp.lang.objective-c
Subject: Re: Objective C vs C++
Keywords: why
Message-ID: <40817@genrad.UUCP>
Date: 21 Feb 91 15:01:51 GMT
References: <60377@eerie.acsu.Buffalo.EDU> <44957@nigel.ee.udel.edu> <45238@nigel.ee.udel.edu>
Sender: news@genrad.UUCP
Lines: 76

In article <45238@nigel.ee.udel.edu>, carroll@cis.udel.edu (Mark Carroll) writes:
] In article <40804@genrad.UUCP> dxb@genrad.com (Daniel A. Burkhard) writes:
] ]In article <44957@nigel.ee.udel.edu>, carroll@cis.udel.edu (Mark Carroll) writes:
] ]
> ]] ... stuff deleted
] ]
] ]] at abstraction. It's completely impossible to implement a class in
] ]] a way where a user cannot change the private parts of the class, or
] ]] alter the class declaration. ............
] ]
] ]How so ?? C++ gives you member access control private (default), public, and
] ]protected. A user has no direct access to private members, i.e private
] ].....
] 
] I'm not talking about during execution; what I mean is that the .h
] file declaring the class MUST be accessible to and alterable by the
] user. A user can muck about inside of the declarations of any class
] which he is permitted to use. In Objective-C, that can be prevented.
] (The private declarations are not necessary to use a class.)

Accessible yes. I assume you think that .h files must be alterable for
reasons you list below --

] 
] ]] C++ is almost completely statically bound;
] ]] dynamic binding only comes into play when you start using virtual
] ]] function, and only functions tagged virtual can be rewritten in your
] ]] subclasses.
] ]
] ]I'm not exactly sure what you mean by "rewritten", but of course something 
] ]like
] ]....[some example redefining some method]
] ]is perfectly legal in C++ [note: no "virtual" here].
] ]
] 
] 
] True. But if I pass an instance of class bar to a function expecting an
] instance of class foo, and inside the function, I call the geta(), I'll
] get foo's geta(), not bar's. If the only OO background you have is C++,
] you'll just say, "Oh. But that's where you use virtual functions". But 
] in "traditional" object-oriented design, ALL functions are "virtual". I
] should be able to reimplement ANY function in a subclass, and have it
] always get called correctly, whether the original author thought that I'd
] want to or not.
] 
] C++ makes the assumption that the original author is fully aware of
] EVERYTHING that the users of a class might want to do with it in
] the future; that's an acceptable assumption, since it's so easy to
] go in, and change the class declarations if he was wrong. In Objective-C,
] no such assumption is made, and it is not necessary to ever alter the
] class declarations in order to be able to make use of the class.

You give the impression that all you had to do is change the .h-file, but
just changing class declarations is not sufficient (is that why you claim that you
need alterable .h files ?) -- you will most likely need to recompile implementations
also; this may be unacceptable in some situations.

The whole issue on whether or not the default for member functions should
be virtual has been discussed to some length in comp.lang.c++. I don't intend
to repeat these arguments here.

This really is not a language issue. The issue is whether or not you believe
that member functions should be virtual; so now it becomes a criteria when
you select components for reuse. Other people may be more concerned with performance,
therefore may have a different set of criteria. But given the code you reuse
satisfies your criteria, you will not need to alter anything. Again, not a language
but an implementation issue.

--dan

-------------------------------------------------------------------------------
Dan A. Burkhard				Internet:	dxb@genrad.com
GenRad, Inc				UUCP:		...!genrad!animal!dxb
300 Baker Ave				Phone:		(508) 369-4400 X3304
Concord, MA 01742		
------------------------------------------------------------------------------