Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!vsi1!apple!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac
Subject: Re: MAJOR MAC IIx PROBLEMS!!!!! APP
Message-ID: <560@internal.Apple.COM>
Date: 7 Feb 89 18:23:19 GMT
References: <35965@think.UUCP> <46100273@uxe.cso.uiuc.edu> <00hRU1eOR21010a14Eo@amdahl.uts.amdahl.com>
Organization: Advanced Technology Group, Apple Computer
Lines: 31

In article <00hRU1eOR21010a14Eo@amdahl.uts.amdahl.com> kucharsk@amdahl.uts.amdahl.com (William Kucharski) writes:

>producing 100% legal Macintosh code.  Basically, I've found that if you
>try as much as possible to play by the rules of the games (read: treat
>Inside Macintosh as a bible) the rules won't be changed from under you (or at
>least _too_ badly :-) ).

In my experience, it also depends on how cautious the developer is.  It is
virtually impossible for us to write down all the things you shouldn't do.

A good example is with the styled TextEdit.  A few program broke when that
came out because we added a handle to the TEHandle.  Some programs were
creating TEHandles by cloning an existing one instead of calling TENew.
This caused problems because the new handle was shared between TEHandles.

There was no explicit rule against doing this (although you could argue that
this was a case of manipulating data structures directly).  

This is an example where the programmer should think about what s/he is
doing.  Bypassing the TENew call, should have raised a red flag, even if you
couldn't think of an explicit reason why it might be a bad idea.  

Whenever you try to do something a bit out of the ordinary, that's the time
to think about how it might fail in the future.


-- 
		 Larry Rosenstein,  Object Specialist
 Apple Computer, Inc.  20525 Mariani Ave, MS 46-B  Cupertino, CA 95014
	    AppleLink:Rosenstein1    domain:lsr@Apple.COM
		UUCP:{sun,voder,nsc,decwrl}!apple!lsr