Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!lll-crg!lll-lcc!pyramid!voder!apple!lsr From: lsr@apple.UUCP (Larry Rosenstein) Newsgroups: net.micro.mac Subject: Re: What are Object Pascal and MacApp? Message-ID: <117@apple.UUCP> Date: Thu, 7-Aug-86 13:23:35 EDT Article-I.D.: apple.117 Posted: Thu Aug 7 13:23:35 1986 Date-Received: Sat, 9-Aug-86 04:42:06 EDT References: <945@unirot.UUCP> Reply-To: lsr@apple.UUCP (Larry Rosenstein) Organization: Advanced Development Group, Apple Computer Lines: 93 If people are interested in finding out about Object Pascal & MacApp, I would suggest that they first look at the August BYTE Magazine, which has several articles on object-oriented programming in general, and MacApp in particular. There is also the book "Object-Oriented Programming for the Macintosh" by Kurt Schmucker. This goes into more detail about the concepts behind object-oriented programming, Object Pascal, and MacApp. It also talks a bit about other object-oriented languages on the Macintosh. Here is a brief description of Object Pascal and MacApp. Both Object Pascal and MacApp are descended from work we did for the Lisa O/S. Object Pascal is based on Clascal and MacApp on the Lisa Toolkit. (Niklaus Wirth did consult for us on the design of Object Pascal.) MacApp and Object Pascal are relatively independent of one another. Object Pascal can be used without MacApp, and MacApp could have been written in any object-oriented language. MacApp is nothing more than a library of code. It is not just a set of procedures and functions (as is the Toolbox or the Pascal Extender product). Taken by itself, it forms a complete Macintosh application that has multiple, resizable windows, can print, save, revert, etc. In that sense it is similar to SKEL. Unlike SKEL, you do not modify the MacApp source code to customize it for your needs. (Although MacApp comes with full source code.) Instead you use object-oriented programming. For example, the contents of a window is drawn by calling the Draw method of a particular View object. The generic MacApp View object has an empty Draw method, but you can make a subtype of View and override its Draw method. When MacApp needs to refresh the window (or print the document) it will call upon your specific Draw method to do so. MacApp implements the basic control structure of your program (which is the same in every application and tedious to write), and calls your specific methods as needed. MacApp does a lot of things for you automatically, such as: window resizing, moving, and zooming scrolling (manual and automatic) printing safely saving documents (i.e., saving to a copy where possible) error handing and reporting displaying the watch cursor handling desk accessories MacApp also includes about 75K of debugging tools. People have been using MacApp for over a year and a half now, both inside and outside of Apple. (Some MacApp users are on the net, so perhaps they will give their own comments about it.) We know of 3 projects that have reached "beta-test" stage: a boat navigation program (described by Larry Tesler in BYTE), a system for teaching introductory programming (MacGnome from CMU), and a program to manage recording studios. (There are other people using MacApp intensively, but we haven't seen demos of what they are doing.) There is some space overhead in using MacApp compared to writing your program in a conventional way. This is due to the fact that MacApp is designed to be very flexible and includes a lot of features. The space overhead for methods is only 1-5K for method tables. Method calls take the same space as regular procedure calls. The performance overhead for using MacApp is also very small. First, you are not required to write the low-level parts of your application using objects. Object Pascal is compiled into native code. You can use assembler if you choose. (We also have assembler macros for doing object-oriented programming.) Second, we have implemented a method call optimizer that automagically changes certain method calls into regular procedures calls that have no performance overhead. In MacApp, we estimate that 60-75% of the method calls are optimized in this way. (The optimizer also reduces the space for method tables by about 5%.) Right now, you need MPW in order to use MacApp, because you need to have Object Pascal. Once TML comes out with its version of Object Pascal, it should be easy to port MacApp to that system. (We are working with Tom Leonard on this.) We are also working on porting MacApp to a subset of C++, but this will not be done for MacApp or MPW 1.0. We are encouraging language developers to add object-oriented extensions to their languages and port MacApp to their environments. If you have any additional questions, let me know. Kurt Schmucker is giving a talk about MacApp at the MacWorld Expo in Boston (Saturday, I think). In addition, many of the people who worked on MacApp will be there, as well as some MacApp users. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.CSNET