Re: COMEDI wrapper (was: Re: Data acquisition in Octave)

[Przemek Klosowski]

   OK, I think we may have the same kinds of problems with this as with
   the comedi_t type.  The real trouble is that Octave just doesn't have
   a pointer (or reference) type, so wrapping bare pointers the way I did
   is probably not the right thing to do.  The reference counting in the
   octave_value class is probably not going to do the right thing for us.

Tcl had an elegant solution for that: the application-specific
structures (sockets, file descriptors, graphics-related structures,
etc) were represented on the interpreter level by simple strings.
Those strings were keys to a hash array, whose values were abstract
pointers to user-defined, application-specific data structures. To
make it easy, the Tcl runtime library had a generic hash table API.

Specifically, each class of objects had a separate hash table, and
each new object, for instance a new file opened, would 

    - create the appropriate file descriptor, 
    - load its address to a FD pointer,
    - generate a unique string name for it ('file1','file2', etc),
    - enter the string/pointer pair as a key/value pair into the
      appropriate hash table.

The interpreter didn't know anything about the underlying structures:
it just passed the key string around between all the procedures that
deal with this particular object. The procedures would implicitly know
which hash table to use to look up and retrieve the internal data.

I guess my point is that there is no reason to shoehorn the comedi_t
structure into an octave-specific data structure; Octave should
interact with comedi_t internals through comedi_t-specific 'class
methods'.