Newsgroups: comp.lang.postscript
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!stanford.edu!lucid.com!campeau!jwz
From: Jamie Zawinski <jwz@lucid.com>
Subject: Re: Bind problems
In-Reply-To: glenn@heaven.woodside.ca.us's message of 5 May 91 17:36:30 GMT
Message-ID: <JWZ.91May5141303@thalidomide.lucid.com>
Sender: usenet@lucid.com
Organization: Lucid, Inc., Menlo Park, CA
References: <1991May5.010114.24826@neon.Stanford.EDU> <488@heaven.woodside.ca.us>
X-Windows: Power tools for power fools.
Date: 5 May 91 14:13:03

In article <488@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) wrote:
> 
> Maybe it's not "bind" that's at fault, but for people (like me) to
> recommend using "load" to tie an operator directly to a user name.
> Perhaps you shouldn't do that unless you're quite sure the name is
> likely to be unique.

I think the problem is using insanely short identifier names.  This isn't
AppleSoft Basic!  If you're doing something like

      /p /show load def

then I can respect that, because it's probably to reduce file size.  But if
you're doing

     /test { /p exch def p show } bind def

then you've probably got no excuse.  Not only does the name "p" have no
semantic content, making the code hard to decipher if it's not a trivial
example like this, but since PostScript has -no- facility for local variables
or lexical scope, you're just asking for trouble.  Every nominally "local"
variable you use is screwing with the global namespace.  Tread lightly.

(I know you can pretend you have dynamically-scoped locals by consing
dictionaries on the fly, but that's a big pain in the butt.)

Anyway, in the

      /p /show load def

example, upcasing the P couldn't hurt either...

	-- Jamie
