>I'd have to agree that they're a huge improvement over the rats-nest
>of casting that has been the hallmark of MacOS programming up to this
>point. But they've definitely got disadvantages too, larger and
>harder-to-read code being the most obvious.
Scott,
well, I always kinda liked that you could pass a WindowPtr anywhere a
GrafPtr was expected without problems. They anticipated one of the most
enjoyable C++ features quite a while ago. But I'm getting off topic. Back
to our regular programming:
>I think maybe the engine should do this instead. That way it doesn't
>have to copy data it needs to keep around when calling an external,
>nor even when it gets data from the external that it can use and keep
>unaltered.
The trouble with this is the mess that is memory management on the Mac. As
I detailed in my other post, we have 4 kinds of memory. We'd have to
provide a memory allocation callback for this to work properly. Do we want
this?
>Sounds like a good goal, as long as we can avoid the "quicksand" that
>opaque structures can evolve into. Ever done any AppleEvent
>programming? The only thing worse than the MacOS rats-nest of casting
>is the ridiculous trial-and-error guesswork required to generate or
>decompose an AEDesc.
Automatic conversion would probably fix most of that mess, and since all
xTalks already have this on the script level, I doubt it would be much of a
problem.
>This could improve performance some, assuming you're passing numbers
>around a lot. But is this a common thing to do?
I rarely do it, though it might be more of an issue when arrays arrive,
because then you'd be able to pass a couple hundred numbers in and out an
external in an array. Under those circumstances, supporting numbers for
parameters might really help. Though I have to admit I haven't yet written
any XCMD that would really have profited of this. But I guess MetaCard and
HyperSense are a little more established in the scientific field, where
number juggling is much more common than in the typical use of HyperCard or
SuperCard.
>These are really the only types all the xTalks use internally
>anyway...
Yup. Though I have a one-stop solution for arrays that wouldn't be much of
a problem to implement (as long as you support associative arrays):
XParamRef GetParamArrayEntry( XParamRef parent, char* index );
This would simply return another XParamRef for a value in an array.
Technically this would even allow nested arrays (i.e. arrays of arrays)
quite easily, though the host would of course need to support that.
However, once we go that way, we'd probably also have to add:
unsigned long GetParamNativeType();
unsigned long GetParamAvailableTypes();
To find out what's the best type for a parameter or what types it can
easily be converted to. You see where this begins to get more and more
convoluted.
>How would it know? And how would it know the type of the argument
>that was passed to it? And would conversion be automatic if you try
>to "GetParamDoubleValue()" when the data was stored with
>"SetParamCharArrayValue()"?
This is really a good point. Either the callbacks would have to return a
flag who owns the value (messy, unelegant) or we would support only the
CopyXXX() callbacks that use a caller-provided pointer to store the data
(lots of copying data, slow, RAM hungry). *sigh*
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
The future of programming: http://freecard.sourceforge.net
