>I think this is an excellent suggestion. It's time to move beyond
>simple C structs and start embracing more robust object-oriented
>approaches.
Doug,
thanks for that vote of confidence. Just one thing: Could you probably
quote less than the whole message? I wrote my message myself, and the
others have seen it on the list. It would save some bandwidth. Thanks. And
now for something completely different:
>I think we should at least include numbers along with strings in our
>list of supported data types. While xTalk languages are essentially
>typeless, allowing the user to treat all data as strings, internally
>they all store numbers as numbers until a string representation is
>called for. So it makes sense to allow externals to accept and
>provide numeric values directly to save some unnecessary conversions.
I have no problem with that. I guess most xTalks store data as native data
types internally, anyway. Those that store everything as strings could just
do a strtod() or something like that on their strings to implement those
callbacks.
>I would suggest we begin the api with the simple types (say, strings
>and doubles) before trying to tackle the more complex or
>implementation-specific ones like arrays and colors.
Coward. <g> ;-)
>char* ParamCStringValue( XParamRef param );
>char* ParamCharArrayValue( XParamRef param, unsigned long *ioLength );
>double ParamDoubleValue( XParamRef param );
>void CopyParamCStringValue( XParamRef param, char** outStrPtr,
> unsigned long *lengthPtr );
>void CopyParamCharArrayValue( XParamRef param, char** outStrPtr,
> unsigned long * lengthPtr );
Since we also have the "copy" calls, I don't mind the ones above. However,
I think the char** is wrong. I wouldn't want to have the "copy" calls
allocating the memory for me. Instead I'd want to be able to pass in a
pre-allocated block to have the data copied to. This is especially useful
on the Mac, where you have at least four kinds of memory: new, malloc(),
NewPtr() and NewHandle(). Could we maybe change the copy calls to:
unsigned long GetParamSize( XParamRef param );
void CopyParamCStringValue( XParamRef param, char* outData );
void CopyParamCharArrayValue( XParamRef param, char* outData );
The CopyXXX calls would take a pointer you allocated and fill it with the
data. Of course, the caller would have to make sure the buffer is large
enough, using GetParamSize().
>Under this scheme, the external is only responsible for freeing the
>memory if it received a copy of the string. In the cases where a
>pointer is returned, it points to memory owned and managed by the
>opaque object.
Well, here's where the problem comes in on Mac. You can't just tell a
programmer on Mac to dispose of the pointer received. There are four kinds
of memory, and since the ANSI C runtime libraries are not part of the OS,
but usually statically linked into the external, every XCMD has its own
version of free() and delete. It is not practiceable to have the XCMD
dispose of memory it received from the host in a cross-platform way, as the
only calls that would work this way are DisposePtr() and DisposeHandle(),
which are inherently Mac-specific. Let the caller create the memory for the
CopyXXX() calls and the problem is solved.
One more thing: I think CharArray is not a good choice of words either. It
can be mixed up too easily with associative arrays and since supporting
those is also a long-term goal, we should make sure to avoid terminology
clashes right away. Maybe "Buffer" or "CharBuffer" or "TextBuffer" ?
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
The future of programming: http://freecard.sourceforge.net
