Mark's recent questions about his RECT class sort of triggered a thought for a way to improve the native APIs and make it easier to write certain types of objects. The native API has two special pseudo types intended to make objects that use backing C structs or C++ classes easier to use. These two types are CSELF and BUFFER. The CSELF type assumes there is an instance variable at the current method scode that contains a Pointer instance that wraps some native code value. Specifying the CSELF type will unwrap that pointer object and pass back the pointer as a void * that can be case to the appropriate type. BUFFER is similar to CSELF, but the data in question is stored in a Buffer object and the pointer returned is to the start of the buffer data. The CSELF generally requires the object have an UNINIT method to ensure that the data is released. The BUFFER type places the native data in storage managed by the garbage collector, and the buffer will be reclaimed when the object holding it goes out of scope. This is handy for objects like a RECT, where you could define things with a C struct or C++ class and there are no additional resources that need to be cleaned up when the object goes away.
This construct is handy for self-contained objects (such as a stream object, which uses CSELF). However, if you wish to wrapper different C structs or classes that are intended to work together, it's somewhat less useful. I'm thinking of a couple of changes here: 1) The runtime can actually figure out that the variable CSELF is a Pointer or a Buffer and do the correct thing. I've never been terribly happy with the BUFFER type name, so I'm thinking CSELF and BUFFER can be collapsed into the single CSELF type and have the runtime figure it out. 2) An ObjectToCSelf() API that can extract the CSELF information for another object would allow objects primarily implemented as native code to operate together better. This will return NULL if not CSELF variable is found in any scope of the instance. 2) Does break the object encapsulation slightly, but it is limited to some special contexts that only make sense for native code. If we're really concerned about this, we could add a tagging MIXIN class that says this operation is allowed. Not sure this is really needed. Rick ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
