Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!cs.uiuc.EDU!johnson From: johnson@cs.uiuc.EDU (Ralph Johnson) Newsgroups: comp.object Subject: Re: The Emperor Strikes Back Message-ID: <1991Feb26.191336.1947@m.cs.uiuc.edu> Date: 26 Feb 91 19:13:36 GMT References: <3351@sequent.cs.qmw.ac.uk> Sender: news@m.cs.uiuc.edu (News Database (admin-Mike Schwager)) Reply-To: johnson@cs.uiuc.EDU (Ralph Johnson) Organization: University of Illinois Lines: 76 Piercarlo Grandi argues with Steve Cook's criticism of Guthry's original definition of an object. steve> What is an object? steve> According to Guthery, 'stripped of its fancy jargon, an object is steve> a lexically-scoped subroutine with multiple entry points and steve> persistent state'. [ ... ] steve> But the most fundamental idea of object-oriented programming is steve> dynamic binding of operation names to operations at run-time. pcg> Dynamic overloading has nothing to do with objects or OO programming; pcg> not all languages that have dynamic overloading/latent types are OO and pcg> not all OO languages have dynamic overloading/latent types. steve> Lexical scoping has nothing whatever to do with objects. pcg> Conversely, lexical scoping is essential to the principal style of pcg> object implementation, the closure based one. The other one being the pcg> one based on continuations (actors) instead of lexically scoped pcg> closures. I will stand on Steve's side here. While closures can be used to implement objects, it is not the principal style. The principal style is that an argument is a record with one field pointing to an array of procedures, and that procedure calling is always done by indirection through this array. This is how C++ and Smalltalk do it, if you are willing to think of a Smalltalk class as an array of procedures. Further, I believe that dynamic binding is essential to object-oriented programming, and hereby declare any programming language without it to be not object-oriented. In fact I am happy to consider languages like Emerald to be object-oriented even though they do not have inheritance, while I would never accept Ada because it rules out dynamic binding. One of the main ideas of an object is that its user does not have to know anything about how to implement operations upon it, that the object is in complete control. Different objects will have the same sets of operations but implement them differently. Any one of these objects can be replaced by any other. This is essential for the development of groups of components that can be mixed and matched with each other. There is nothing wrong with a language implementation that tries to bind operations as early as possible, but that is an optimization. In short, if C++ did not have virtual functions, it would not be object-oriented. steve> Can somebody who's failed so completely to grasp the basic idea steve> be trusted to criticise the whole technology? I agree. I read Guthry's article a year or so ago and thought it was mostly wrong. I sent him a detailed (and polite) discussion of the paper but he seemed to ignore it, because he published his article without any changes. Perhaps my letter didn't get to him in time. As far as I can tell, Guthry only made one good point. That point was that object-oriented programming panders to the worst side of hackers, the side that wants to build tools for building tools for building tools, without ever getting anything out the door or having to worry about meeting deadlines. OOP people say that developing libraries of reusable programs requires a lot of time and lots of iteration and that it is hard to predict how long it will take or even if it is done. This makes OOP very hard to manage. Guthry is right. The OOP people are right. However, this is only discussing the design of libraries of reusable components. If you are just trying to build applications then it is not as important for the software to be reusable. Reusable software is wonderful to use, but hard to develop. You should buy it from someone else if at all possible. You should never try to develop it yourself under a tight schedule. Ralph Johnson -- University of Illinois at Urbana-Champaign Brought to you by Super Global Mega Corp .com