Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucbvax!decwrl!nsc!voder!apple!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Design Philosophy
Message-ID: <13346@apple.Apple.COM>
Date: 5 Jul 88 18:36:10 GMT
References: <434@dogie.edu>
Reply-To: lsr@apple.apple.com.UUCP (Larry Rosenstein)
Organization: Advanced Technology Group, Apple Computer
Lines: 49

In article <434@dogie.edu> terranova@vms.macc.wisc.edu writes:

>    A friend of mine recently expressed his disapproval of the standard
>Macintosh program design.  Rather than putting windows, menus, icons,
>def procs, strings, controls, etc. in resources he would prefer to
>hard code everything into the program and make heavy use of #define
>statements.  He would change the #defines instead of the resources.
>"That's why they made the preprocessor."

The main motivation for using resources was to allow programs to be
customized for international markets without recompiling them.  All that you
need to localize a progam for France, for example, is the original English
version and a resource manipulation tool (ResEdit, etc.).  This is very
important for commercial applications, because non-US markets are
significant, and it is impractical to recompile the code for each country.  

It is also convenient to place user configuration information in resources.
Because the Resource Manager looks for resources along a path of open files,
you can put the default resource in the application, and override the
default with a resource in the preferences file, or in the document file (to
override on a per-document basis).

In many cases, placing this information in a resource (as data) takes up
less space than spcifying the equivalent information programmatically.  The
more information you put in the resource the more this savings will be.
Imagine creating a dialog box programmtically vs. specifying a dialog
template.

The only disadvantage of using resources is that it requires another step in
the application build process.  On the other hand, once you have the
resources defined, it is not necessary to rebuild them.  If you embed the
equivalent information one of your code files, it will be rebuilt whenever
that code file is recompiled.  

I can see how it might be easier to get things running without using
resource if you were using Lightspeed C, because LSC doesn't have a resource
compiler/editor integrated in the environment.  Unless you were using
MultiFinder, you would need to exit LSC to create the resources.  

Another factor in using LSC is that compilations are so fast, that it
doesn't matter if you have to recompile a file to change the position of a
window.  In MPW, however, it takes less time to recompile your resource file
than recompiling and relinking your code.  

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