🚀 go-pugleaf

In article <724322275.6320755@AppleLink.Apple.COM>, BERDAHL@AppleLink.Apple.COM (Taligent, Eric Berdahl,PAS) writes:
>  
> 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.

You may be technically correct about Apple making an announcement. Surely, they
showed intent openly to developers.

At the last developers conference, I repeatedly quizzed Tom Chavez, and he
assured me that OSL support would be in the next release of MacApp. I felt
that while MacApp 3.0 was a step forward, support for all the new system
features was desparately needed.

We agreed that it wasn't necessarily MacApp's intent to replace the toolbox.
So, for some system features, no "MacApp support" was really necessary. 
Developers could simply call the toolbox in their appropriate methods.

However, some system features really needed to be worked into the framework.
OSL is one of them. 

I also got somewhat frustrated at the developer's conference where Apple would
repeatedly state that developers should use MacApp for new development, but
when presenting information on new technologies, MacApp support was no where
in sight. (Witness: AppleScript, QuickDraw GX) 

The technology teams claimed that such integration was the responsibility of
the MacApp team. The MacApp team screamed that they couldn't possibly keep
up with all the technology being developed.

Obviously, proper management and cooperation inside Apple is missing. Both
teams should have worked together to mutually support both the technology and
the framework.

Then in June, the bomb dropped, leaving developers without a satisfactory
development framework for the forseeable future. 

IMHO, Apple has really bumbled this one. It would have been one thing to
support Bedrock when it was ready to ship. But cutting MacApp off at the
knees in a half finished state wasn't very smart. And Bedrock may still
be a year or more off. Who knows? Symantec isn't saying. All Apple developers
can do is plod along and wonder what is going to happen, and whether they should
switch over to doing Windows development. (bleah)

> 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.

Indeed. These are the sorts of things that should have been worked into 
MacApp 3.0 when it first shipped.

> 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. 

Agreed. Even MacApp 2.0 is good.

Isn't it a shame that Apple has chopped off development and is only providing
minimal (life) support to MacApp?

> 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. 

Since Apple should have obviously provided this, we developers wonder why
they didn't. That and the fact that repeated promises that they would
support this doesn't sit well.

> Well, anyways, I hope that helps clear things up. Is MacApp dead? That's a
> silly question. Of course it isn't. 

MacApp isn't dead, but it is in the ICU, on minimal life support.

> It is stagnant? Only the future will decide that.

It is hard to have much of a future when you are on life support....

	-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.