🚀 go-pugleaf

Attn: MacApp 3.x Tech Discussion
SentBy: Eric Berdahl
 
        Reply to:   RE>MacApp demo code ?
Thomas,
 
I'm touched that you enjoyed the article on Object Model support, but I think
you missed the point altogether. Or, maybe you didn't and you're just making
some great hyperbolic point.
 
But before I go on with that discussion, let's set some facts straight.
 
First off, I don't believe that Apple ever announced OSL support for MacApp.
They kept talking like there would be a 3.1, and that it would have Object
Model support, but they were very careful not to make a clear commitment. That
was one of the more annoying things about this whole mess is that they would
never say what they would do other than think about it. Meanwhile, developers
are left hanging in the breeze.
 
Second, the unsupported unit would never have worked. That was one of the
central points of my presentation at MADACON '92: that you need underlying
architectural support for scripting concepts, they can't be just pasted onto
an application or a framework.
 
Third, the so-called unsupported unit is not what appears in the develop
article. I do not work for Apple. During the five weeks I did work for Apple,
I had nothing to do with the MacApp project. The MacApp group has never
approached me about adding UAppleObject functionality to MacApp, and even when
I had a prototype running, the only thing that happened was that I made the
changes to MacApp available to the MacApp team so they could see how I thought
it should be done.
 
Ok, now that the world axioms are realigned, let's get on to the substance of
your comments.
 
Why should you write MacApp code when even I wrote an article about object
programming without mentioning MacApp? There are lots of reasons. MacApp is
the best class library available today for doing Macintosh development.
Period. Another interesting journal is FrameWorks, The Journal for Software
Developers using Object Technology. In the September '92 issue of that journal
is an editorial I wrote on this very topic, "Is MacApp Dead?" [For the
morbidly curious, backissues can be gotten from the MADA office,
408-253-2765.] So the answer to why you should develop with MacApp is that you
need to ship product today and not wait for something the *might* come
tomorrow.
 
So, why did I choose not to mention MacApp more than I did? That's an
excellent question.
 
One reason is that there was an entire community of non-MacApp developers that
haven't seen my ideas for Object Model support expressed in either design,
theory, or code. They, too, deserve to have solutions presented to them.
 
Second, there are a great many people who still don't believe that things like
multiple inheritance, other C++ features, or even C++ are useful tools. The
Object Model problem cries out for just this kind of solution (which should
not be a surprise to anyone who was at the MADACON presentation), and I
thought I could do it justice in code. You'll have to be the judge of whether
I succeed.
 
Third, if the choice is to do everything in MacApp and make the rest of the
world convert out of MacApp or do everything in pure C++ and make the MacApp
community convert, I'll choose the latter. In general, I find that members of
the MacApp community are some of the brightest and resourceful people in the
community. No bull here, I mean that. I didn't think it would be a problem for
any MacApp developer to convert that code into an appropriate list of changes
to MacApp, especially since the roadmap for how to do that is in the last few
slides from the MADACON '92 presentation.
 
Fourth, any article discussion how to patch MacApp itself is going to be
either too long or too narrowly focussed to be printed in develop.
 
Fifth, what I would have printed would go something like this:
"Since MacApp is not based on multiple inheritance, and has little in the way
of low level frameworks, all MAppleObject functionality must be added by the
individual developer to TObject. TAppleObjectDispatcher functionality must
likewise be patched into TApplication in order to provide proper AppleEvent
distribution over and above MacApp's mechanisms. This will give you the
mechanics to have Object Model support in MacApp, but you will likely be very
unhappy with the result. Since MacApp has a rich library of classes that
should be providing default Object Model behavior, just adding the mechanics
are not enough. Instead, you will probably find yourself compelled to add such
behavior to MacApp itself, out of a sense of indignity at Apple forgetting
such a vital part of the architecture. For example, TWindow should implement
the close AppleEvent. There is no reason that every application needs to do
that, using TWindow itself should be sufficient. Unfortunately, since Apple
didn't see fit to provide this functionality, you get to."
Something tells me that the editor wouldn't have printed that.
 
Well, anyways, I hope that helps clear things up. Is MacApp dead? That's a
silly question. Of course it isn't. It is stagnant? Only the future will
decide that.
 
Stirring regards,
Eric