🚀 go-pugleaf

Darcy Brockbank writes
| In article <20JUL92.11345443@enh.nist.gov> aoml@enh.nist.gov writes:
| > I need to have a couple of variables which are specific to the particular
| > nib section that is loaded.  (I have several of the same nib files on  
| > screen at the same time, but each must have its own, discrete data set).  I
| > figure that by putting these variables in the @interface section of the
| > header file, they will be specific, like I need.  However, a large part of
| > my file consists of regular C functions (which run faster, I think, than  
| > methods).  When I put the variables in the @interface section, my functions
| > can no longer see them.  I can see what is going on here, and where my  
| > problem is.  Does anyone know of a better way of handling this than
| > changing my functions into methods?  Thanks.
| > Kevin
| 
| Variables declared in the interface section are global only to that object's
| methods, and the subclasses of that object.

Actually, @interface variables are not global in the K&R sense.  They are local  
variables whose scope includes the object and its subclasses.  Just like a  
recursively called function will have multiple copies of the same variables,  
multiple objects each have their own copy of the @interface variables - they  
are not global.

| In order to make private variables that are also available to
| an object's functions you can make static declarations within the
|  .m file. You wan't have access to those variables from subclasses
| though.

Warning: static variables are global and not created for each instance of the  
object.  The original question indicated a need for each nib section that is  
loaded to have its own discrete data set - static declarations will not provide  
discrete instance variables.

To answer the original question, about the only way to have discrete instance  
variables accessable by regular C functions would be to allocate a structure  
every time you load the nib section and pass the pointer to this structure to  
the regular C functions whenever you want to operate on a particular instance  
of the nib.  Basically you would have to rewrite the Objective-C runtime - so  
why not use it?
-- 
Brian Willoughby	Software Design Engineer, BSEE
BrianW@SoundS.WA.com	SoundSoftware
NeXTmail welcome