BAMADA Notes

James Plamondon

February

The amazing total of 107 people turned up for the February meeting of the Bay Area MacApp Developers Association (BAMADA). Maybe it was the advance advertising; maybe it was the increasing use of MacApp; maybe it was the move from Wednesdays to Thursdays. Whatever it was, we had to bring in more chairs.

CoverTest

Most likely, the big turnout was a reaction to the all-star lineup we had on the agenda. The night led off with Steve Jasik, who demonstrated CoverTest, a code-coverage testing tool. It looks like it will do a great job of helping testers and developers work together to ensure that their code has been exercised as fully as possible. If your code needs some exercise, keep an eye out for CoverTest. Jasik will be shipping it with The Debugger sometime in May of '92.

Jobs and books

During the break in presentations, a number of job openings were announced. As usual, there were many people looking to hire, and none looking for work. In MacApp programming, the unemployment rate must be negative. Recession? What recession?

Also during the break, I had the pleasure of announcing the publication of Alger and Goldstein's new book, "Developing Object-Oriented Software for the Macintosh." It is a seminal book on managing the development of software, starting from the only first principles that matter: what works. It lists for $26.95 in the US and $34.95 in Canada.

In addition, Bruce Tognazzini's "Tog On Interface" has just been released. Tog is Apple's User Interface God-In-Residence, and his book is a great piece of work-especially page 210. (David Yost paid me a dollar to say that. Read the book and find out why.)

Memory management

We ended our announcements when Mike Burbidge of the MacApp Team was ready to take the floor with his presentation on "Memory Management in MacApp 3." The short synopsis is: it's complicated, but not as complicated as you think it is. Basically, you need to use a debugger to help find the "high-water mark" of memory usage in your application, and set the appropriate field in MacApp's 'mem!' resource to reflect that usage. Then, you can be sure that every allocation that has to succeed will, because MacApp will have pre-allocated enough storage for it to work.

Mike also went into the difference between temporary and permanent allocations, and why they were named the way they are (which has always struck me as backwards). Our heads swimming with all of this valuable but complex information, we gave Mike a big round of applause for a job well done (great slides!), and hoped to see this stuff written down somewhere soon, so that we could actually figure it out.

Failure handling

Then Lonnie Millet, MacApp 3 Technical Lead, launched into a detailed and meticulous discussion of "Failure Handling in MacApp 3." The adoption of C++ has both simplified and complicated failure handling in MacApp 3. It's simpler, because you can use macros to simulate ANSI C++ 3's try/throw/catch mechanisms (which are not yet implemented directly in MPW C++); it's more complicated, because the Object Pascal way of handling errors must still be supported. I wonder why we can't just throw some dirt on Object Pascal's coffin, and get on with our lives? No matter how dearly beloved, Object Pascal is a dead language. (Please, no snide remarks about Eiffel being stillborn, OK?)

The message was clear: one way or another, you've got to handle errors gracefully-and doing so means designing your app's error handling at the start, not two weeks before its ship date. Lonnie's careful and practiced presentation covered much more material than I could possibly synopsize here-but I hope you'll be seeing a Frameworks article on this topic soon.

While preparing the next presentation, Tom Chavez asked the assembled host whether they would prefer to have future MacApp documentation be perfect bound (like Inside Mac) or three-hole punched with binders (as it is currently shipped). The general consensus was that no one cared much one way or the other, although I think perfect binding was gaining momentum there towards the end. You, too, could cast your vote on these momentous issues, simply by attending BAMADA meetings! Who knows what thorny topic we'll grapple with next month?

Swatch

Last, but surely not least, Joe Holt of Adobe demonstrated Swatch, a segment-watching application. Although neither written with nor aimed specifically at MacApp, Swatch is nonetheless an great tool for MacApp programmers. It displays the heaps of all running applications-rather like the old HeapShow program, but in living color and in a very cool interactive fashion. An application's heap is shown as a bar in a window, a lot like the Finder's display of application's memory use in the "About the Finder" window.

In Swatch's heap bars, green blocks are free memory, red blocks are locked, and orange blocks are purgeable. When you see a red blocks show up in your heap, you know you've got a memory sandbar, and can expect to see your app's performance suffer. By clicking on a block, you can get a lot of useful information about it-where it starts, whether it's a resource or data, and so on.

You should rush out and buy this program-but you can't, because Joe's giving it away for free! Hurry and send him a blank, formatted disk right now (Adobe Systems, 1585 Charleston Road, Mountain View, CA 94039), before I talk him into selling it for $50 a pop. In the meantime, be a sport and enclose a check for $10 with the blank disk. If he really doesn't want it, he can always send it back.

March

I can't tell you what happened in the first few minutes of the March meeting, because I was 25 minutes late. I think it was fate getting even with me for snickering at the guys who arrived late to their own sessions at the '92 MADA Conference in Orlando. OK, guys, I think I understand better now. I apologize.

Dinker

By the time I arrived, Kurt Schmucker already had his audience spellbound. His presentation on Dinker was, like Dinker itself, up and running.

Apple currently classifies Dinker as "experimental and unsupported." It has been exercise of Apple's Advanced Technology Group (ATG), with a lot of help from the Donoho Design Group and a few notable individuals, among them Jed Harris and Joost Kemink. It was developed specifically for the System 7 Finder, but with MacApp in mind.

Dinker allows an application to dynamically link, or "dink," classes into an application at run-time. Say, for example, you have an application which needs to import and export lots of different file formats-and you know that new file formats will be coming out after your application ships. Currently, you can address this need using Claris' XTND technology, but XTND isn't object-oriented.

With Dinker, what you do is implement a base class called, say, TFileTranslator, and statically link it into your application. You could then write a number of TFileTranslator subclasses-one for each file format you wanted to support-and compile each in a separate Dinker extension. Then, when your application launched, it would find whichever of these Dinker extensions happened to be on the disk, and link them in dynamically.

Then, when someone ships an app with a new file format that you want to support, all you need to do is write a new TFileTranslator subclass for that file format, compile it into a new component, and ship it-no modifications to your existing code are necessary. The user just drops the component file onto their drive (in the right place, of course), and-voila!-when your app starts, it finds and dinks in the new component, and the user can read and write the new file format.

Further, if you published your TFileTranslator base class' interface, third parties could write their TFileTranslator subclasses for you.

The ability of a developer to extend a class library is what makes MacApp worthwhile. Dinker just allows you to postpone some of this extension from link time until launch time. Let's see-if "launch time" is between link time's "early binding" and run-time's "late binding," we can call it either "just-in-time" binding, or maybe "siesta binding" (since it's just after launch). Nah.

Dinker in MacApp 3.1?

Kurt made the point repeatedly during his talk that he wanted as much feedback as possible from people as to how they thought they might want to use Dinker. Now that MacApp 3 has shipped, MacApp 3.1 is being planned-and one of the features under consideration for inclusion in 3.1 is direct support for Dinker.

For example, if the TFileTranslator class were in MacApp itself, then it would provide a standard mechanism for implementing import/export in applications. MacApp would know that there might be Dinker extensions to TFileTranslator laying around, so it would look for them at launch time.

Likewise, wouldn't it be cool if you could tell ViewEdit about the TControl subclasses you wrote for your application? If you compiled each of them into a Dinker component, then maybe a future version of ViewEdit could look for and use those components. Then ViewEdit could manipulate and edit your TDial or TWhatzit controls just like you can your TButton controls.

The MacApp Team is looking for other cases in which MacApp could be primed to take advantage of Dinker extensions. If you think of any, let them know-if enough people need it, maybe they'll do it, so you won't have to.

Dinker is not without its drawbacks. Since it is postponing some linking until launch time (and we all know how long linking takes), launching a Dinker-aware application is somewhat slower than launching a non-Dinker-aware app. Building an app is also a bit slower (but not much).

Likewise, you do have to do some work in your application to prepare it for subclassing via Dinker. For example, to implement built-in support for TFileTranslators, MacApp would have to know that it should look for dinked extensions to TFileTranslator at launch time. This isn't so much a drawback of Dinker as it is a fact of life: you can't get something for nothing. In this case, you can't find Dinker extensions unless you know to look for them.

Also, component files remain open while their base application is running. If you have a lot of dinked-in extensions, this may be a problem in System 6, because it had a limit on the number of files that could be open at any given time.

For more information on Dinker, see Kurt's article in the January 1992 issue of Frameworks. Dinker shipped on ETO #6. It will also be shipping in a new and improved form on ETO #8 (it just missed the deadline for #7).

Dylan

After Kurt polished off the last of the Q&A, we turned over the floor to James Joaquin of Larry Tesler's Advanced Products Group (APG). He announced that the object-oriented dynamic language that they're working on, and that was the topic of Larry's keynote address at the '92 MADA Conference, would henceforth be called "Dylan." While he didn't deny that it was named as a tribute to Bob Dylan (which would imply that it was really cool, but hard to understand), he said that the name came from the phrase "DYnamic LANguage." He emphasized that this language is not a commercial product, nor even a beta version thereof, but rather that it's a research tool being used within APG.

Nonetheless, if you can't sleep without knowing what Dylan's all about, he said that you could go ahead and give 'em a call. He didn't promise to tell you anything if you did, though. (Maybe the ATG is actually a front for AT&T, and they're just trying to get you to confess that you think C++ is less than perfect, so that they can round you up with the other subversives once C++ takes over. It fits, right? Let's call Oliver Stone!)

April

Next month, we will continue our new tradition of trying to confuse our members about when and where we meet, by moving to the De Anza Three Auditorium. De Anza Three is right across the street from the Any Mountain Ski Shop, on the corner of De Anza and Mariani Boulevards. The meeting will be held at the usual time-7pm-and on the usual date: the second Thursday of the month, which in April falls on the 9th. We've moved the meeting to the De Anza Three Auditorium (DA3) because a) with over 100 people attending some meetings, we've outgrown our current location; b) DA3 has great videotaping equipment, and lots of people have expressed an interest in getting tapes of the Bamada meetings; and finally, because c) you can get into the DA3 Auditorium without having to sign in, which will make life easier for everybody.

Also, next month will be the first meeting at which we will be charging admission. MADA members get in free; MADA memberships will be on sale at the door, at the usual cost of $75 (checks only, please). Apple employees will also get in free-they're providing the venue, after all; it would hardly be polite to charge them admission to their own auditorium. Everybody else gets to pay five bucks at the door (in cash, checks, rubles, or whatever). (According to a show of hands at the March Bamada meeting, of the 55 people attending, only about 7 (12%) would have needed to pay admission, under these rules.) We have to start charging admission to provide the money to pay for the guard at the De Anza Three Auditorium, which we didn't need to pay for at the old location.

The Grand Unified Theory

And a guard will certainly be necessary, to hold back the screaming crowds that will undoubtedly turn out to hear Eric Berdahl's presentation on "MacApp, AppleEvents, and the Object Support Library: The Grand Unified Theory." This will be the Reader's Digest Condensed Version of the all-day talk he gave on the subject at the '92 MADA Conference in Orlando. His talk was so popular then, that when he left the hotel afterwards, hotel personnel had to disperse the crowds by using bullhorns to announce that "Mr. Berdahl has left the building."

Don't miss this once-in-a-lifetime opportunity to see and hear Mr. Eric Berdahl, President of MADA, personage at Taligent, star of promotional videos, speak on the Grand Unified Theory. At the '92 MADA Conference in Orlando, Steve Weyl, Apple's Manager of Developer Tools, said that this stuff may find it's way into the next version of MacApp. So if you want to know what the future of MacApp holds for you, you don't want to miss this session.

Be there or be tetrahedral!