Re: Problems with createActionTo and arg types...

[Roger M. Burkhart]

Alex Lancaster writes:

> Thanks for all the suggestions. I had thought about making turning the
> amplitude
> into an object - but not representing the float as a series of integers.
> These
> are all good workarounds - but my basic question is still - is this
> limitation
> intentional or an unavoidable consequence of implementation? If so, is the
> limitation
> at the level of gcc or ObjC (i.e. is it just *not possible* to cast a float
> to an id)
> - or of the Swarm activity library itself? In other words, is this a *known*
> limitation of this method?
> 
> If this is "just the way" it is - I think making the float into an object is
> probably the way to go - it just seems like somewhat of an overkill to pass
> objects
> when you only really want to pass a number! (No offence to Pietro!)

This is "just the way it is" in the current form of action creation
messages.  I wasn't aware that the compiler refused to cast a float to an
id type, but we were aware of the restriction on double types (which are
obviously uncastable as they're twice the size).  The standard work-around
would be the same as for doubles: if you don't want to go all the trouble
to create an object, then declare the method to accept an argument of type
float * or double *.  Then pass the address of a float or double value in
the createAction message, casting it to (id).  When you need the float or
double value in the method, dereference the passed pointer to get it.

This technique avoids the need to create a whole object just to hold your
value, but you still need to be very careful to pass the float or double
address from some allocated location that will actually still be around
whenever the scheduled action is called.  Do *not* pass the address of a
local variable where you call the createAction message, because that
calling context will no longer exist when the createAction message is
called.  If the float or double is already contained as an instance variable
of an object that will still exist at the time of the call, it's safe to
pass that address.  If you've got no convenient container for the float
or double, it may still be just as simple to create an object to hold the
value and pass that address, or else you could allocate a raw storage block
just to hold the float or double.  Whatever you allocate, you also have the
responsibility to free the allocation whenever it's no longer required by
the action.  The address of a static variable is also safe, but it's hard
to create multiple actions that way that each refer to their own values.
Wherever you allocate the value, be aware that the action will not take
value at the time of action creation, but the current value at that address
when the action is actually executed.

The current technique of creating actions is the fastest and most direct
when you've got compatible argument types, but obviously inconvenient for
floats and doubles.  More generic ways of creating actions are possible,
based on taking argument values off a variable argument list according
to declared types of the action's message selector, but this is
potentially more error-prone and carries extra overhead.  We could
add support for both methods of action creation if the interest is great
enough.

In the meantime, the best I can suggest is to pick your favorite form
of workaround from those that have been suggested.

Roger Burkhart


                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================