Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!lsr From: lsr@Apple.COM (Larry Rosenstein) Newsgroups: comp.sys.mac.programmer Subject: Re: OOP--What do you think? Message-ID: <51823@apple.Apple.COM> Date: 22 Apr 91 18:10:39 GMT References: <1991Apr10.210516.25812@rice.edu> <51593@apple.Apple.COM> <17229@hoptoad.uucp> Organization: Future Stuff, Apple Computer, Inc. Lines: 77 In article <17229@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > >On the other hand, it's awfully slow to keep up with both Apple's Human >Interface Guidelines (see pop-up menus, for instance) and the features You'r probably right about this. >that people have been using in real commercial applications for years: >features like floating windows, document-window menu bars, >keyboard-walked menus, and so forth. It doesn't even support a basic Since MacApp is used as the basis of many applications, the MacApp engineers have an extra responsibility to make sure that MacApp will be compatible with various system releases. In general, this means sticking to features that are supported in the system. >feature like enabling and disabling of dialog buttons depending on >whether there a selection in a list or text in an editable box, which What's the problem exactly. Can't you disable a button if you choose? Your comments about undo in non-frontmost documents probably should be changed. >MacApp is barely flexible enough for any sort of real commercial >programming, and almost surely too inflexible for anything really >innovative like HyperCard. A while ago, Keith said that no one who had Tell that to the companies shipping products based on MacApp. >>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. >Which simply says that the low-level interface wasn't designed very well, >and the MacApp team has managed to do better (they think). This doesn't An OO approach allows you to implement a framework, so that the system can take care of the standard behavior. A feature like Publish/Subscribe is going to require some (mostly) standard code as well as application-specific code, regardless of how you design the interface. In that case, the OO approach is going to work better than writing the common code over and over. >>procedural manner. For example, an AppleEvent is much like an object (there >>are event classes of AppleEvents). > >Well then, given the virtues of OOP, you shouldn't need MacApp to make >the system easy to use, should you? Right. If the system has an OO interface, then you wouldn't need a "wrapper" like MacApp. >I'm sold on object-oriented programming, but the above are frivolous >arguments. In what way? >That is, provided that there is some small method which is perfectly >placed to let you make just the change that you want. This is rarely >the case. Far more often, you're faced with the change-source/copy-and-edit Then the library is designed wrong. Designing a reusable framework is very hard, and MacApp has many reusability problems, which get fixed over time. In most cases, the methods are placed properly and the framework works. >Furthermore, it's almost always necessary to familiarize yourself with >the internal details of the class you are modifying and most of its Then the documentation needs to be improved. There's no question that MacApp has flaws, but most people who use it find that it saves them time and works very well. -- Larry Rosenstein, Apple Computer, Inc. lsr@apple.com (or AppleLink: Rosenstein1)