Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!pt.cs.cmu.edu!pt!dld From: dld@F.GP.CS.CMU.EDU (David Detlefs) Newsgroups: comp.lang.c++ Subject: Re: objective C Message-ID: Date: 8 May 89 16:15:11 GMT References: <2614@ssc-vax.UUCP> <3180@stpstn.UUCP> <15327@gryphon.COM> <1546@sw1e.UUCP> <162@mole-end.UUCP> <1562@sw1e.UUCP> Organization: CMU CS Department Lines: 60 In-reply-to: uucibg@sw1e.UUCP's message of 5 May 89 13:13:02 GMT In the ongoing Obj-C vs C++ discussion, Brian Gilstrap writes: >Suppose you're provided with class 'sprocket' which someone else wrote. Then >class 'sprocket' would be a service supplier to other classes which you write. >A class which you write which makes use of 'sprocket' would naturally be a >client of 'sprocket'. Now, lets look at where strong typing restricts things >and also improve type-checking (you can decide which is more important, since >I've been heavily flamed already). >If class 'sprocket' takes arguments, then it must decide upon the types of >the arguments that it takes. Assume that 'sprocket' takes at least one >object as an argument. [I'll interpret this as meaning that at least one of sprocket's member functions takes an argument of a class type.] >C++ requires that you provide a type for that argument >in the form of a formal parameter in the .h and .c files. This restricts you >to a member of that class or one of its sub-classes (nothing new > here). But >lets look at a pretty generic member function (method) like 'print' or >'display'. You could easily expect to create classes not derived from the >same superclass and have them incorporate a 'print' method (or 'display' or >whatever). Yet C++ requires you to make a choice when writing the supplier >as to what classes are valid objects (at least as far as 'sprocket' is >concerned). [I don't exactly understand the last sentence, myself.] I don't want to get into the depths of this discussion, but I would like to point out one tool that can bring the two sides closer together: generic classes and functions. If I may paraphrase Brian's example: if 'sprocket' uses a type in a minimal way, say it just prints and displays it and maybe calls == on it, then inheritance is probably not the right mechanism to get type-safety, since we don't want to use multpile inheritance to create a "PrintableDisplayableandComparable" class, from which many others inherit. Instead, we parameterarize 'sprocket' over the type T, and instantiate it to get the actual 'sprocket' types we need. Completely type-safe, no run-time "message not understood" errors. Presently, we would have to do this using big hairy macros (or something like Doug Lea's 'proto' program for libg++), but eventually there will probably be language support (Stroustrup has published a possible design for such a mechanism.) With compiler support, there may not even be much duplicated code for multiple instantiations of the same type. classes, then 'sprocket' can take the parameter parameter. Having used languages providing both, I think if I had to choose one of inheritance and parameterized types, I'd take the latter. But that's a little reactionary. I'd rather have both. Also, Bertrand Meyer's Object-Oriented Software Construction has a good discussion on the proper use of inheritance vs. genericity. Trying to keep an open mind... -- Dave Detlefs Any correlation between my employer's opinion Carnegie-Mellon CS and my own is statistical rather than causal, dld@cs.cmu.edu except in those cases where I have helped to form my employer's opinion. (Null disclaimer.) --