Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!lsr From: lsr@Apple.COM (Larry Rosenstein) Newsgroups: comp.sys.mac.programmer Subject: Re: OOP--What do you think? Message-ID: <51593@apple.Apple.COM> Date: 16 Apr 91 23:53:32 GMT References: <1991Apr10.210516.25812@rice.edu> Distribution: usa Organization: Object-Based Systems, Apple Computer, Inc. Lines: 86 In article <1991Apr10.210516.25812@rice.edu> koops@elf.rice.edu (Ryan Richard Koopmans) writes: > >What I want to know is, is OOP the wave of the future in >programming or just a passing fad? Is it worth learning >a new way of programming just to use the TCL? If you already have programmed the Macintosh, then using TCL/MacApp might seem like a waste of time, since you do have to fit your code into someone else's application framework. On the other hand, you do get the benefit of features that you might not have tackled yet. (I haven't looked at TCL, but I know that MacApp handles a lot of nitty-gritty details that I don't think many casual programmers take the time to worry about.) I also think OOP is the wave of the future. As one example, look at the new IAC facilities in System 7. First, implementing IAC in an application will be much easier using MacApp 3.0 than if you were trying to do it yourself. You will find that there are a lot of little details about when to call various routines that could/should be handled for you by an appropriate framework. Second, you should notice that the interfaces to these features (esp, AppleEvents) are strongly object-oriented even though they were done in a procedural manner. For example, an AppleEvent is much like an object (there are event classes of AppleEvents). The same thing applies to any graphical user interface (Windows, X, ...). Each of these environments is gaining new features (eg, Microsoft OLE), which makes it more difficult to write applications. >Maybe I'm just old fashioned, but I like the straight procedural >way. In all the message passing and things, I feel that the >programmer gets too far away from the machine and works on a >too abstract level. The problem is that unless you create some kind of abstractions, you will be unable to fully implement a satisfactory application. The ROM is already pretty far away from the machine, but most people don't try to implement their own graphics package, menus, etc. You can implement abstractions with a set of utility procedures, but the problem is that simple procedures can't be easily customized. You can vary parameters to a call, but you can't modify what goes on inside a procedure. With OOP, you can override one method in a class an change a small aspect of its behavior. To respond to some other comments: There is a perception that OOP programs are big and slow. I think this is a myth. There are many MacApp-based programs on the market, which I think demonstrate otherwise. MacApp's code makes up a small fraction of a typical program. This perception comes from: (1) people looking at a MacApp program with debugging code compiled in (which adds 50-100K and slows the program by a factor of 2+) or (2) people comparing a MacApp program with one with less functionality (MacApp's simple text editor vs. TeachText). (I think the reason that applications are getting bigger and bigger is that developers feel the need to add more and more features. Part of the reason is to distinguish their program. Part of the reason is that reviewers seem to give more weight to features, so a program that does one thing really well loses out to one that does many things less well.) A method call in MPW Object Pascal takes no more space than a regular procedure call. Also, we implemented an optimization scheme in which the time overhead for calling a method id proportional to the number of times it is overridden. If you don't override a method (the most common case in a framework like MacApp) then calling that method is exactly the same as a normal procedure call. In straight C++ (ie not using Object Pascal-compatible classes) method calls take more space, but less time. (The time to call a method is constant, and not much more than a regular procedure call.) There will be some space and time overhead for using an application framework, due to the fact that one can more tightly code a specific application, than a general framework. But the OOP application will be easier to extend and maintain. -- Larry Rosenstein, Apple Computer, Inc. lsr@apple.com (or AppleLink: Rosenstein1)