LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (April 2002, week 5)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:   Mon, 29 Apr 2002 15:54:54 -0400
Reply-To:   "Fehd, Ronald J." <rjf2@CDC.GOV>
Sender:   "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:   "Fehd, Ronald J." <rjf2@CDC.GOV>
Subject:   Re: poll: user-defined readonly macro variable
Comments:   cc: Ian Whitlock <WHITLOI1@WESTAT.COM>
Content-Type:   text/plain; charset="iso-8859-1"

> From: Ian Whitlock [mailto:WHITLOI1@WESTAT.COM] > I think you are missing the point that global variables are > poor way to > design complex code systems. Each time a macro uses a global > variable one > of the conditions required for proper operation of the macro > is left hanging loose with no indication of its origin.

Yes, I have to agree with that statement. This is why I suggested that the readonly status be allowed to be set in only one place, i.e., the autoexec.

> I don't know that having constant variables is bad and I can > imagine some might feel more secure with them.

Peace of Mind, for me, is soft-coding, rather than hard-coding. Each time I have had to change a hard-coded reference in my dozen projects' umpteen files, I have changed the reference from hard- to soft-coded references using %global macro variables.

My favorite example Monday morning lasted until Wednesday 3pm, when the SysOps changed the LAN drive letter where all my projects were stored from R to U. This is when I found that UltraEdit could open 100 files, and do a Find&Replace in All Open Files :-) and I needed to change 128 files. :-\

> However, I would far more prefer evolving > to a system where one can pass arguments by value > and guarantee that nothing passed to a helping macro > can be modified by the helper in the callers space.

I agree that this is Good Coding Practice.

However, you and I know we work with people whose eyes glaze over when they read your statement above. And we will have to fix their Coming-Up-to-Speed Coding Practices.

> The real question is just how much improvement > one can ask for in a macro language. > It's very implementation simplicity argues against > it ever being very easy to use.

LOL "Too much of a Good Thing, is still a Good Thing." -- Mae West

Ah, The SAS Macro Language: Very Simple. Therein lies its power: good small tools, with which we build Bigger&Better Tools. Which we don't want to drop on our, or anyone else's, feet.

> (Macro knows nothing about SAS and vice versa.)

<sigh> much to our chagrin.

Ron Fehd the macro maven CDC Atlanta GA USA RJF2@cdc.gov

By using your intelligence you can sometimes make your problems twice as complicated. -- Ashleigh Brilliant


Back to: Top of message | Previous page | Main SAS-L page