Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!rice!uw-beaver!zephyr.ens.tek.com!tektronix!reed!orpheus
From: orpheus@reed.UUCP (P. Hawthorne)
Newsgroups: comp.sys.mac.programmer
Subject: Re: HLock Function List
Message-ID: <16129@reed.UUCP>
Date: 22 Feb 91 12:20:57 GMT
References: <1991Feb20.042807.12553@ux1.cso.uiuc.edu> <6484@skye.cs.ed.ac.uk>
Reply-To: orpheus@reed.UUCP (P. Hawthorne)
Organization: Reed College, Portland OR
Lines: 34


  Nick Rothwell writes:
. My approach: assume that *any* trap can move memory (well, except BlockMove,
. which I use to copy stuff between handles and the like).


  I do this. So far so good. It makes it easier for me to write code, not
having to worry about getting the state of a handle recorded correctly at
each turn. I choose to assume the worst, and unlock my handles only on
special occasions, like when I want to repack my zone or something.
  Others have pointed out, though, that it is possible to keep track if you
want to. Also, it has been pointed out that you should be able to depend on
the documentation about what moves memory, no matter what.

  It strikes me that you need to be more aware of this in C than in Pascal,
since as I remember Think C, one must be familiar with the details of a given 
trap's parameters and use pointers if appropriate.
  Using Pascal, though, I find myself much more interested in what my
project ought to be doing than what my zone is doing, in general.
  Distinctly different approaches, but equally valid depending on context.


  I wonder sometimes if, when an object moves in memory, whether there is
any danger in using the methods of that object. Is there a chance that the
method would not be found because the object's type could not be found, 
perhaps branching to some low memory location?
  Must one be using locked handles in order to call methods?



  orpheus@reed
 "Don't tell me about politics. Our problem is the economics...
  When you cannot have that which you don't own,
  you scream and shout... all day long..." - New Order