Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!rutgers!bellcore!texbell!sw1e!uucibg From: uucibg@sw1e.UUCP (3929]) Newsgroups: comp.lang.c++ Subject: Re: objective C Message-ID: <1562@sw1e.UUCP> Date: 5 May 89 13:13:02 GMT References: <2614@ssc-vax.UUCP> <3180@stpstn.UUCP> <15327@gryphon.COM> <1546@sw1e.UUCP> <162@mole-end.UUCP> Reply-To: uucibg@sw1e.UUCP (Brian Gilstrap [5-3929]) Organization: Southwestern Bell Telephone Co Lines: 90 In article <162@mole-end.UUCP> mat@mole-end.UUCP (Mark A Terribile) writes: [ This, by the way, was written by Brad Cox as I recall ] >> >>... reusing code involves binding a supplier's code with a consumer's code >> >>long after the supplier's code has been compiled (and therefore bound to >> >>whatever types the supplier knew about at the time...which fails to >> >>include the consumers') ... >Not so. In general, something invoked through a calling sequence doesn't have >to know the name of the thing that invokes it. If it is to use some resources >that are passed to it, it has to know what they are ... but it can present an >interface (a class) to be filled in and passed to it so that the resources are >presented on the invokee's own terms. > >There's really no magic. Ummm, I think you got that backwards. Then again I could be brain-fried (I've been working a lot of long days and programming at home into the wee hours). The terminology used in Brad's description can be rather confusing. Let me try again and see (1) if I can describe it well and (2) just how much I can get flamed by the c++ true-believers :-). 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. 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). This means that the person writing the code for the supplier must decide a priori what tasks 'sprocket' might be usefull in solving. But the whole point of writing suppliers it to avoid making decisions about what kinds of problems can be solved with code for 'sprocket' and instead let the client programmer look at available classes and decide what to use. It seems extremely painful to coerce the inheritance tree to try to avoid these kinds of situations. Furthermore, the 'precompiled classes' scenario prevents this option anyway since you can't control the inheritance tree of the precompiled classes you (theoretically) buy from some software vendor. This means (as Brad pointed out above) that I can't pass any instances of my gee-whiz 'super_cog' class to a 'sprocket' even though my 'super_cog' has a 'print' member function (method). This severely limits the reusability of the code for 'sprocket'. I don't have enough experience with multiple-inheritance to comment on its ability to solve this problem (at least I perceive it as a problem). Anyone care to comment? Now, before you get out your flame-throwers, let me reiterate that I realize that there are advantages to OO other than reusability. In particular, encapsulation helps tremendously with debugging, correctness, and I'm sure there are others I've missed. However, *IMHO*, reusability provides the greatest potential benefits in the long run if we can develop techniques to support it. To me, OO should be one of these techniques. However, it seems to me that C++ lops off some (many?) of the possibilites through its strong typing of objects. Okay, maybe the strong typing of objects helps in other ways (I'm not convinced of that yet); maybe multiple-inheritance will help change fix the problem I've described above. I don't know. Again, anyone care to comment? >> This gives me an opportunity to clear up a question I've had for quite a >> while. Is it possible to do the following: [ my silly question here ] > >The answer is most definitely YES. The class declaration contains all that Okay, so I was seriously derranged when I wrote that :-). Sorry I wasted the net bandwidth (seriously, though the resulting discussion has been interesting). Please forgive it as a case of no-sleep-does-strange-things-to- the-brain. >(This man's opinions are his own.) >From mole-end Mark Terribile Brian R. Gilstrap Southwestern Bell Telephone One Bell Center Rm 17-G-4 ...!ames!killer!texbell!sw1e!uucibg St. Louis, MO 63101 ...!bellcore!texbell!sw1e!uucibg (314) 235-3929 ...!uunet!swbatl!sw1e!uucibg #include