Re: Spam:Spam:Small DLLCC Enhancement and questions.

Comrades,

         as part of my work enhancing the DLLCC front end, I've developed a standalone enhancement to DLLCC that enables customisation of the datum wrapper classes.

If you have a DLLCC struct definition like this:

  OSXFuseLibrary>>fuse_args

    <C: struct fuse_args { int argc; char **argv; int allocated; } >

then doing this for example:

   OSXFuseLibrary current fuse_args gcCalloc

will return an instance of CCompositePointer. The same thing happens if you call a function that returns a fuse_args* struct, or access a member of another struct that is a fuse_args*, and so on. Of course you might get a CComposite if you access by-value. You have to access the struct members using #memberAt:/#memberAt:put:/#refMemberAt:

My enhancement allows you to do this for example:

  OSXFuseLibrary>>fuse_args

    <CX: pointer=Nitro.FUSE.FuseArgsPointer datum=Nitro.FUSE.FuseArgs >

    <C: struct fuse_args { int argc; char **argv; int allocated; } >

This means that rather than CCompositePointer being returned, a Nitro.FUSE.FuseArgsPointer (which must be a subclass of CCompositePointer) will be returned, in every situation where fuse_args* is used. If your API is pointer-focused then you won't need the datum spec, in which case CComposite will be used for by-value returns.

The obvious benefit is the FuseArgsPointer can not only have accessors/setters but can also contain other methods, such as external library routines applicable to the datum etc.