FROM : David Casseres
DATE : Fri Jul 04 04:02:47 2008
I've run into this many times, and I think I've used all the
techniques you mention and some others less hygienic. I've been most
satisfied with your 2) and 3) solutions. There's not really that much
overhead in making a struct or Obj-C class for two specific kinds of
values, and once you've got it you know exactly what you're doing at
all times. I like structs becaus they're so lightweight, and I like
Obj-C classes (with properties, yay!) because structs are so ugly to
declare.
I note that Cocoa itself uses all these techniques, but maybe they
lean toward structs with a few specialized functions for working with
them, for constructs that will be used often like NSRange. On the
other hand there's NSIndexPath; since it's a class, UITableView can
create a category on it that provides properties. Very nice.
On Jul 2, 2008, at 11:48 AM, James Montgomerie wrote:
> Say I have a method that needs to return two equally important
> values (in my case, a string and an offset into it). I am
> overthinking how to do it, and I though it would be interesting to
> see what others have done.
>
> I see these opportunities (my use of 'object' and 'value' is blurred
> below, since I'm thinking of the abstract case - assume that both
> values could be objects):
>
> 1) Just return the first value, and have the caller supply an
> argument that the second value gets written into (akin to how
> NSError is customarily used). This seems a bit unclean, since one
> value is not more important than the other, and both are necessarily
> returned.
> 2) Define a custom C struct (like NSRect, but with e.g. 'string' and
> 'offset' members) and return objects in it. Just like any other
> returned objects, the caller would be expected to retain them
> individually if it needed to keep them around.
> 3) Define a custom Obj-C class with two properties [e.g. 'string'
> and 'offset'] and return an object of that class (with properties
> appropriately set).
> 4) Create a 'Pair' C struct with two ids in it. Use it like the
> custom struct in (2). This struct is more reusable than the one in
> (2), so this solution seems less 'heavyweight', but it is less
> descriptive.
> 5) Define a 'Pair' Obj-C class with 'first' and 'second' properties,
> use as (3). Again, more reusable, less 'heavy' seeming than (3),
> but less descriptive.
> 6) Return an NSArray with two items in it (this seems the least
> descriptive option, from the point of view of someone reading the
> header).
> 7) Return an NSDictionary with two items in it, keyed by their
> property names. This seems a bit wasteful, since the dynamicisim of
> a dictionary is not required, and is also not so descriptive from a
> header-reading perspective.
>
> Oh, and there's also 8) Rename the file .mm, and use a C++
> std::pair<id, id> class. (Only joking :-)
>
> How would you do this? Are there other, better options?
>
> Jamie.
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>
DATE : Fri Jul 04 04:02:47 2008
I've run into this many times, and I think I've used all the
techniques you mention and some others less hygienic. I've been most
satisfied with your 2) and 3) solutions. There's not really that much
overhead in making a struct or Obj-C class for two specific kinds of
values, and once you've got it you know exactly what you're doing at
all times. I like structs becaus they're so lightweight, and I like
Obj-C classes (with properties, yay!) because structs are so ugly to
declare.
I note that Cocoa itself uses all these techniques, but maybe they
lean toward structs with a few specialized functions for working with
them, for constructs that will be used often like NSRange. On the
other hand there's NSIndexPath; since it's a class, UITableView can
create a category on it that provides properties. Very nice.
On Jul 2, 2008, at 11:48 AM, James Montgomerie wrote:
> Say I have a method that needs to return two equally important
> values (in my case, a string and an offset into it). I am
> overthinking how to do it, and I though it would be interesting to
> see what others have done.
>
> I see these opportunities (my use of 'object' and 'value' is blurred
> below, since I'm thinking of the abstract case - assume that both
> values could be objects):
>
> 1) Just return the first value, and have the caller supply an
> argument that the second value gets written into (akin to how
> NSError is customarily used). This seems a bit unclean, since one
> value is not more important than the other, and both are necessarily
> returned.
> 2) Define a custom C struct (like NSRect, but with e.g. 'string' and
> 'offset' members) and return objects in it. Just like any other
> returned objects, the caller would be expected to retain them
> individually if it needed to keep them around.
> 3) Define a custom Obj-C class with two properties [e.g. 'string'
> and 'offset'] and return an object of that class (with properties
> appropriately set).
> 4) Create a 'Pair' C struct with two ids in it. Use it like the
> custom struct in (2). This struct is more reusable than the one in
> (2), so this solution seems less 'heavyweight', but it is less
> descriptive.
> 5) Define a 'Pair' Obj-C class with 'first' and 'second' properties,
> use as (3). Again, more reusable, less 'heavy' seeming than (3),
> but less descriptive.
> 6) Return an NSArray with two items in it (this seems the least
> descriptive option, from the point of view of someone reading the
> header).
> 7) Return an NSDictionary with two items in it, keyed by their
> property names. This seems a bit wasteful, since the dynamicisim of
> a dictionary is not required, and is also not so descriptive from a
> header-reading perspective.
>
> Oh, and there's also 8) Rename the file .mm, and use a C++
> std::pair<id, id> class. (Only joking :-)
>
> How would you do this? Are there other, better options?
>
> Jamie.
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>
| Related mails | Author | Date |
|---|---|---|
| James Montgomerie | Jul 2, 20:48 | |
| Abernathy, Joshua | Jul 2, 20:56 | |
| Stephen J. Butler | Jul 2, 20:58 | |
| Jean-Daniel Dupas | Jul 2, 21:14 | |
| Andy Lee | Jul 2, 21:22 | |
| Andy Lee | Jul 2, 21:30 | |
| Joel Norvell | Jul 2, 21:33 | |
| Bob Smith | Jul 2, 22:03 | |
| Keith Duncan | Jul 2, 22:19 | |
| David Casseres | Jul 4, 04:02 |






Cocoa mail archive

