|Date: ||Thu, 22 Jun 2006 16:32:19 +0000|
|Reply-To: ||toby dunn <tobydunn@HOTMAIL.COM>|
|Sender: ||"SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>|
|From: ||toby dunn <tobydunn@HOTMAIL.COM>|
|Subject: ||Re: macro structure|
|Content-Type: ||text/plain; format=flowed|
If you are only going to call it once then perhaps you dont need too use
macros at all or perhaps you dont need to have the second macro A.
During World War II the British started noticing that many of their bombers
where getting shot down. They were getting shot down not from losing a wing
or something as drastic as that but rather from bullet holes in the bombers
gas tank. They also noticed that the German planes did not suffer from
this. A quick investigation revealed that the German bombers had
self-sealing gas tanks. The British quickly decided that they needed to do
something to improve their bombers gas tanks. The intelligence/scientist
working with the British government, R. V Jones, investigated and found that
at the end of World War I Britain has actually developed a bullet proof gas
tank. However, since was developed at the end of World War I it was also
decided that the gas tank should be not only bullet proof but crash proof
since crashes where the major cause of death to the pilots then. Well
needless to say they never could come up with both a bullet proof and a
crash proof gas tank, so the whole concept was forgotten about. Along these
lines another scientist proposed that the best material to develop
motorcycle crash helmets out of was plate glass. Well it doesn’t take a
rocket scientist to deduce that while plate glass was great for visibility
and did a good job at keeping the bugs and elements off of the riders head
it wouldn’t fare so well when the rider crashed.
So what does bullet /crash proof gas tanks and plate glass motorcycle
helmets have to do with macros? Well they are perfect examples of getting
the problem correct. Macros are at their best when they do one thing and do
that one thing well. When the problem is miss specified the macro will
either try to do much, leading to the macro becoming overly complicated and
inflexible. This case is much like the gas tank example above, the real
problem was that they needed to only be bullet proof, the addition of crash
proof over specified the problem and since they couldn’t find away to have
both the project was dropped. On the other hand miss specifying the problem
can lead to the macro not doing enough to solve the problem, this is similar
to the crash helmet example above. While the plate glass helmet does
provide great visibility it does not protect the rider when a crash occurs.
Now one other thing to consider, suppose you need to expand the program.
This is reasonable as alot of use get this request. You find that you need
to functionality of macro A but you dont need the all the overhead of Macro
Main. If you use your second example your screwed, you have to call macro
Main to get to use macro A, which I bet you a dollar to a doughnut wont work
for variaous reasons. If you went with your first example there would be no
problem. Macro Main simply calls macro A, and if you need to use macro A in
another macro or somehwere else outside of a second macro frame work there
is no problems you just call it. This is call loose coupling and is
something you should strive for in your programs. It provides modularity
and flexability while alleviating people reading, using, and modifying your
programs from having to know everything that is going on in your programs or
macros at the same time. We humans have a limited amount of cranial space
and whie we are very creative we are also very error prone. Since programs
arent simple things (ussually) we need to do everything we can to simplify
the problem. Modularity, coupling, cohesion, comments, eternal
documentation, paying attention to the flow of the program, using well named
variable names, using white space, indentation, and watching which methods
and procedures we use really really makes a huge difference.
From: "Huang, Ya" <Ya.Huang@amylin.com>
To: "toby dunn" <email@example.com>,<SAS-L@LISTSERV.UGA.EDU>
Subject: RE: macro structure
Date: Thu, 22 Jun 2006 09:01:22 -0700
But I only call %main once, even though it has a looping inside calls
%a multiple times.
From: toby dunn [mailto:firstname.lastname@example.org]
Sent: Thursday, June 22, 2006 8:59 AM
To: Huang, Ya; SAS-L@LISTSERV.UGA.EDU
Subject: RE: macro structure
Yes, with macro one both macros A and Main only get compiled once. With
your example 2 Macro A gets compiled everytime macro Main gets executed.
From: Ya Huang <ya.huang@AMYLIN.COM>
Reply-To: Ya Huang <ya.huang@AMYLIN.COM>
Subject: macro structure
Date: Thu, 22 Jun 2006 11:52:59 -0400
%do i=1 %to &xx;
%do i=1 %to &xx;
So for structure 1, two macro are separated in two files, %main
can call %a because of the auto macro call library.
For structure 2, %a is defined inside %main, but before the looping.
Is there significant benifit of 1 over 2?