On Feb 22, 2014, at 1:44 AM, jonat...@mugginsoft.com wrote: > On 22 Feb 2014, at 00:12, Ken Thomases <k...@codeweavers.com> wrote: > >> On Feb 21, 2014, at 3:17 PM, jonat...@mugginsoft.com wrote: >> >>> So I want to be able to send the same message to any class and get an >>> appropriate void* pointer. >> >> There's no one representation of its content, so there's no way for any >> recipient of a supposed "pointer to that content" (however that might be >> obtained) to interpret the pointer. > Not so. > The pointer is ultimately passed as a vararg along with a Mono method > representation as part of a Mono method invocation. > The Mono method representation includes type info for its parameters. > Hence it can cast and deference a void* pointer appropriately.
My point is not about the recipient. It's about the NSNumber. There's no one representation of an NSNumber's content. Keep in mind that NSDecimalNumber is-a NSNumber. Any Cocoa API which gives you an NSNumber may in fact be giving you an NSDecimalNumber. It's not documented what the byte-wise value of an NSNumber is, so I can't see how your type info could allow you or Mono to dereference it. > In the above if key is an NSNumber containing a 5 then [key monoValue] > returns a pointer to a 5. This betrays the flaw in your thinking. There's no such thing as "a pointer to a 5"! You can have a pointer to an int which contains the value 5. Or a long which contains the value 5. Or a char which contains the value 5. Or, and this is the killer, a completely custom representation which only means "5" when interpreted by the NSNumber's own methods. A pointer without the knowledge of which specific storage type it's pointing to is almost useless. Certainly, any recipient of that pointer could not reliably extract the value 5 from it or compare it to any other pointer to see if they contain the same thing. For example, what makes you think that two NSNumbers which compare equal have the same size and byte-wise representation (as output by -getValue:) as each other? First, one may have been created with +numberWithChar: and the other with +numberWithUnsignedLongLong: and may have consequently used totally different internal storage for the value. Second, there may be padding within the internal representation which is ignored by NSNumber's methods but which would make the data buffers unequal. > If the key is an NSString then [key monoValue] returns a pointer to a > monoObject representing the string. > >> If you have some specific representation in mind, then don't use NSNumber. >> Use a custom class wrapping the specific representation you want to use. > The custom class would simply be a dupe of NSNUmber + 1 method. > My original category solution seems simpler. Other than being fatally flawed, sure. The point of implementing your own class is that you would control the representation. It's a reliable way to get meaningful pointers that anything knows how to interpret. I wouldn't expect your custom class to be a total reimplementation of NSNumber because you probably don't need NSNumber's generality. In fact, since you need Mono to interpret the pointed-to value, there's probably a limit to how general the class can be. Regards, Ken _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
