id type used as token and Distributed Objects

  • I have a protocol :

    @protocol RSActivityDisplay
    - (id) createActivity;
    - (void) endActivity:(id)activityToken;

    - (void) setActivity:(id)activityToken infoString:
    (NSString*)inInfoString;
    @end

    And two processes (client and server if you like) where the protocol
    is used via Distributed Objects. The (id) value returned by
    createActivity is an internal class to the server that I have no
    desire to expose.

    setActivity: infoString takes the string and calls an internal method
    so :

    [activityToken setInfoString:inInfoString];

    This works fine - I assume because of the use of proxy objects, since
    the value given for the token doesn't match with what was returned
    from createActivity

    endActivity does:

    [activityToken release];

    However this doesn't actually lead to dealloc on my underlying object.
    I assume I'm really just releasing the proxy and it doesn't forward
    the invocation ? I'm sure I don't have any dangling references of my
    own making since I've tested this without Distributed Objects and
    there are no problems.

    Reading the documentation it seems like I need the id return value to
    be handled as 'by reference' ? Is that correct ? I don't need the
    proxy object - but I can't quite seem to fathom the mechanisms/methods
    needed for the by reference to be used and/or the proxy to go away.

    Thanks

    Andrew 8-)
  • On Sep 30, 2007, at 10:56 PM, I wrote:
    > I have a protocol :
    >
    > @protocol RSActivityDisplay
    > - (id) createActivity;
    > - (void) endActivity:(id)activityToken;
    >
    > - (void) setActivity:(id)activityToken infoString:
    > (NSString*)inInfoString;
    > @end
    >
    > And two processes (client and server if you like) where the protocol
    > is used via Distributed Objects. The (id) value returned by
    > createActivity is an internal class to the server that I have no
    > desire to expose.

    Well... it was a little late when I wrote this (in my defense). The
    solution to this is pretty trivial - instead of returning/using the
    (id) type just return/use (size_t) type instead. DO will pass this
    unchanged (since it's a base C type). I can just cast the value back
    (C Style) to what I know it to truly be, and I'm guaranteed to be 64
    bit safe since size_t tracks the pointer size.

    Andrew 8-)
previous month october 2007 next month
MTWTFSS
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
Go to today