Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!ssc-vax!cxsea!blm
From: blm@cxsea.UUCP (Brian Matthews)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Design Philosophy
Message-ID: <2425@cxsea.UUCP>
Date: 5 Jul 88 20:23:19 GMT
References: <434@dogie.edu>
Reply-To: blm@cxsea.UUCP (Brian Matthews)
Organization: Computer X Inc.
Lines: 81

terranova@vms.macc.wisc.edu writes:
|Greetings,
|    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."
|    I am interested in other peoples thoughts on this.  Aside from
|being able to modify parts of the program without recompilation, what
|advantages are there to putting everything into resources?  What
|disadvantages are there to having all code with no other resources?

Some reasons to use the resource manager:

1.  As you state, there's no need to recompile to localize a program.
Also, even if your friend never plans on producing non-English versions
of his programs, that doesn't mean that someone else might not.  With
resources, anyone with the program and a resource editor (at least 3 of
which exist that I know of) can do the localization.  Without resources,
whoever does the localization has to have the source code, a compiler
appropriate to the language and dialect the source code was written in,
and enough knowledge of that language and dialect to be able to make the
changes and still have some small hope that the application will still
function.

2.  Even if someone doesn't want to localize, it's quite common to add or
change command key equivalents on menu items, move dialog boxes about,
etc.  I do this all the time, and it wouldn't be possible if the software
didn't use resources.  Again, even if I could get the source (which I
most certainly can't for things like the Finder, Excel, etc.), I
certainly don't want the vast array of compilers I would need.

3.  Because resources can be released or purged so as to not take up
memory, your application will generally use less memory if it makes
proper use of resources.  Consider error message strings.  Putting the
strings in the code means that they are sitting in the Mac's memory
whenever your application is running, even though they may never or only
rarely be used.  If they're in resources, they only get pulled into
memory the few times they're needed.  Same with dialog and alert
templates, windows, pictures, etc.

4.  Other applications can access the data your program uses if it's in
resources.  The most obvious example is the Finder.  The Finder can grab
the icon and version string (in System 6.0) from an application because
they are stored in resources.  If they're stored as part of the
application's code, the Finder won't know where to look, so it won't be
able to display anything for that application.

|What's
|it like in the real world (outside a university)?

There are very few commercial applications that don't make full use of
resources.  The only one I can think of is from a big software company in
Redmond, WA.  Other than that, all commercial applications, and most
shareware/freeware/public domain applications use resources.  Resources
certainly aren't just curiousities that only Apple software uses.

|    His method is simpler to get some code running.  In fact, I use
|quite regularly for this purpose.  Then, once the code runs the way I want
|it, I move data and def/filter procs into a resource and change NewControl()
|to GetNewControl() (for example).

I suppose this is a matter of taste, but I find it's much easier just to
use resources from the start.  Getting menus, dialogs, windows, etc.  to
look right is much easier to do by twiddling with them in ResEdit and
actually seeing what they'll look like than compiling some code, making
some changes, compiling some code, making some changes....  Also, if you
care about testing your software, you'll have to retest everything once
you move to resources, so why not just start there?  Also, I don't care
how fast your compiler compiles, the less source it has to compile, the
faster it will do so.

It's clear that if your application (or computer) supports languages
other than English (and scripts other than Roman), you have a much bigger
potential market.  Apple recognized this, and came up with a very clean
solution to the problem, namely resources.

-- 
Brian L. Matthews  blm@cxsea.UUCP   ...{mnetor,uw-beaver!ssc-vax}!cxsea!blm
+1 206 251 6811    Computer X Inc. - a division of Motorola New Enterprises