March 92 - BAMADA Notes
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.
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).
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!)
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!