Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcvax!cernvax!cgch!warw
From: warw@cgch.UUCP (Anthony R. Wuersch)
Newsgroups: comp.windows.news
Subject: Re: Structuring NeWS PostScript code
Message-ID: <829@cgch.UUCP>
Date: 30 May 89 10:01:53 GMT
References: <7440@hoptoad.uucp>
Sender: news@cgch.UUCP
Organization: WRZ, CIBA-GEIGY Ltd, Basel, Switzerland
Lines: 55

John Gilmore brings up two issues, directory stacks and lightweight
process management.  Also the general problem of reading NeWS code.

I've started reading the 1.1 NeWS libraries lately.  My suggestions
are based on what I've had to scribble in the columns of my code
printout.

* Empty the operand stack as early and as often as possible.

  Let 'eat-two' == { pop pop } .  Then

       arg arg eat-two
       arg arg eat-two

  is easier for me to read than

       arg arg arg arg eat-two ... eat-two .

  Emptying the operand stack is like executing a statement; I'm
   just asking for the simplest statements.

* Use a distillery application.  Don't flow analyze and optimize by
   hand.  Distilling seems to me the way to handle naming problems.
   Use the names you want.  Let distillation wipeout the names you
   don't need at runtime.

  It's unfortunate for we readers that undistilled NeWS names cost
   so much.

* It looks like there are three kinds of directory stacks:

  - *environments* are stable and contain lots of procedure defs
     added on the fly

  - *class instances* are instantiations of abstract data types,
     i.e., collections of data and procedures which are replicated
     from a class [ some named dictionary ]

  - *local bindings* are scratch directories which a distillery program
     could put on the stack  [ *we* do that now with PostScript, but one
     can dream ]

  Environments should have names.  Class instances and local bindings
   should cite the environment [and/or class instances] they need in
   a side comment.

* Use class instances instead of processes to store data.

* Create new lightweight processes *only* to catch events.

  Maybe there are further *practical* uses for lightweight processes
   [ I'm open to suggestions ], but I wonder what.  I'd rather reload
   a class instance event handler than spawn anew.

Toni