Path: utzoo!attcan!uunet!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!apple!portal!cup.portal.com!Chewbacca From: Chewbacca@cup.portal.com (Paul Frederick Snively) Newsgroups: comp.lang.misc Subject: Re: what is c++, c, ansi c etc... Message-ID: <28922@cup.portal.com> Date: 14 Apr 90 16:32:52 GMT References: <6000:Apr720:31:1490@stealth.acf.nyu.edu> <28742@cup.portal.com> <3916:Apr1317:06:2390@stealth.acf.nyu.edu> Organization: The Portal System (TM) Lines: 41 brnstnd@stealth.acf.nyu.edu writes: [description of OOP system done solely with C macros deleted] I think we're functionally agreeing to disagree. :-) My basic point was that your description was incomplete; the system that you describe having implemented sounds like it fits my conception of OOP better than the definition that you posted. I didn't mean to imply at all that OOP cannot be achieved in a "non-OO" language; that would be silly. Most C++ translators are merely preprocessors to C. A great many object systems in Lisp are created by some fairly simple fiddling around with closures and continuations. I see the current emphasis on OOP as _legitimizing_ the approach in much the same way that structured programming was legitimized by languages that, to one degree or another, enforced a structured approach to writing code. I can write structured pretty-much-anything, even assembly language, if I want. Similarly, I can write object-oriented pretty-much-anything, if I want to write the support code myself, but why bother when there are languages that institutionalize it? For what it's worth, I think there _is_ a cultural gap involved--I've seen too many good programmers find themselves in a time capsule of their own construction because they didn't wish to apply any new methodologies--whether of their own creation or not--to the tasks facing them. Some of them have gone on quite nicely in environments that tend to be pretty technologically stable. Others, such as in my world (I work in Macintosh Developer Technical Support at Apple Computer) move in a considerably faster-paced world: the OSes and application-development toolkits keep getting larger and more complex every day. The Mac OS/Toolbox by now has well over 700 calls available to developers, and the architecture is, frankly, pretty weird. OS/2, X-Windows, SunView, etc. developers are faced with similarly large application interfaces. OOP tends to help factor the complexity of such systems by allowing the developer to easily map from the concrete to the abstract: you can see a window on the screen. It is an object. As such, the window object consists of these data structures and knows how to do these things (instance variables for the data structures, methods for the things it knows how to do). If nothing else, it seems to me that the OOP methodology (apart from any language that may or may not implement that methodology) is quite useful in the world of graphical user interfaces.