Re: struct variable definition (in var.h)

[John Darrington]

On Mon, Nov 08, 2004 at 11:33:57AM -0800, Ben Pfaff wrote:
     John Darrington <address@hidden> writes:

     > There are several `plans' in the back of my mind.  I've yet to
     > seriously think through their relative merits:
     >
     > 1.  Forget the whole thing.  Just let each command allocate the data
     >     it needs on the heap, and keep track of what variable it belongs
     >     to.
     
     I considered this, and looked at what it would take.  It's
     unfortunately very convenient to be able to access data directly
     by dereferencing through a variable.  Otherwise in some cases a
     mapping from variable to extra data, such as a hash table, may be
     needed.
     
     Still, this might be the right way to do it.  I doubt that the
     extra map is really needed in many cases.  In reality I think I
     was just lazy in some places and ended up doing what was "easy"
     and "obvious" instead of what made sense long-term.
     
     This solution will probably require the most work in the short
     term, but I think it would pay off.
     
     > 2.  Have a generic (void *) pointer instead of the union.  Commands
     >     will still be required to allocate and deallocate the memory, but
     >     the pointer keeps track of the variable to which they refer.
     >
     > 3.  As above, but have each command register a function to allocate
     >     and de-allocate the memory.  Some lower level of PSPP (which I'll
     >     call the `allocator') will call these functions as appropriate. 
     >     The allocator will need to provide an interface which commands
     >     will use to declare which variables are of interest.
     >
     > No 3 requires more work to begin with, but will probably pay off as
     > more commands are added (provided I get the model sufficiently general
     > to cater for most of the commands).  This option also provides the
     > opportunity for statistics to be persisted between commands.
     
     #2 seems kind of reasonable.  #3 makes me a little nervous
     because it seems to conflate two problems that may be separate.
     I think that we should consider the two problems (ugly unions in
     struct variable, and caching calculations) separately, and then
     if the best solution to each independently turns out to be #3
     then it's the thing to do.
     
     I'm leaning toward #1, for what it's worth.
 
OK.  In that case, I'll finish coding EXAMINE assuming that's the way
w're going to go.  When that's complete, we can go back and look at
this again.

BTW, if you're not intending to use src/workspace.[ch] can I delete
them?  They're causing `make distcheck' to fail.

J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://wwwkeys.pgp.net or any PGP keyserver for public key.

pgp4lhLXRJZt5.pgp
Description: PGP signature