3

What is the best way to represent a maybe type in Objective C without using pointers? I can not simply use a pointer to a pointer to an object, because a pointer to a pointer to an object is not an object, and I need it to be an object.

I know one way to do this is to have a custom class for each object I have, which would result in classes like, MaybeEmployee, MaybeOrderStatus, and many more custom classes. This would work, but it seems kludgy, and not like a very good solution at all.

The second way to do it, having simply a Maybe class also seems wrong. The lack of type safety is just plain bad.

Molly Stewart-Gallus
  • 1,118
  • 9
  • 25
  • creating interface and `respondsToSelector` call is not sufficient? – Marek Sebera Jun 09 '12 at 21:37
  • You can just use the object and get the class directly. See: http://stackoverflow.com/questions/2055940/how-to-get-class-name-of-object-in-objective-c – hotpaw2 Jun 09 '12 at 21:39
  • @MarekSebera I don't understand what you mean by that comment, can you go into more detail? – Molly Stewart-Gallus Jun 09 '12 at 21:41
  • `+[NSNull null]` is generally used for this. Afterwards check your objects: `if((NSNull *)myObject == [NSNull null]) {...}` – v1Axvw Jun 09 '12 at 21:42
  • @hotpaw2 so you are suggesting that I should simply have one maybe type, discard static type safety and use dynamic type checking instead? I already mentioned that possibility, but it's fair enough if you think that that's the way to go. – Molly Stewart-Gallus Jun 09 '12 at 21:44
  • @lef2 I think that approach doesn't work. Every [NSNull null] points to the same instance, I want to do something like [[Maybe alloc] initWithNothing], but stronger typed. – Molly Stewart-Gallus Jun 09 '12 at 21:49
  • Forget any maybe types. The Employee and OrderStatus objects can tell you their class directly. No other objects needed. – hotpaw2 Jun 09 '12 at 21:55
  • @hotpaw2 That doesn't make sense. How would I create a nothing object, unless I had a Maybe type? Using nil wouldn't work, because I can't mutate an object to be nil. – Molly Stewart-Gallus Jun 09 '12 at 22:03
  • An Employee object with a nil employee name or employee number (etc.) would be of the Employee class. – hotpaw2 Jun 09 '12 at 22:13
  • @hotpaw2 that's basically what I'm doing right now; however, it's not a good solution. I would like to do one assignment to make an instance nil, like self.contents=nil, but with better type safety. – Molly Stewart-Gallus Jun 09 '12 at 22:18

3 Answers3

1

lef2 has the right idea. Use NSNull to represent the "maybe not" case.

The simplest way to handle it is to make your method return an object of type id, but as you say, that sacrifices type safety.

I'd suggest creating an ancestor class MaybeClass and make all your classes derive from that. Then you can create a specific subclass maybeNot that is really an NSNull.

Note that you can also just use standard objects, and return nil when the result of a method call is empty. Objective C handles nil object pointers much more cleanly than a lot of other languages. It's perfectly valid to send messages to a nil object. They just get dropped.

Duncan C
  • 128,072
  • 22
  • 173
  • 272
0

I'm not sure exactly what a "maybe type" means to you, but is there a reason why id isn't sufficing?

Shaggy Frog
  • 27,575
  • 16
  • 91
  • 128
  • 1
    A maybe type is a parametrically polymorphic type which for some type a is a nothing value, (not a null value), or a just a value. The key reason nothing is different from null is that one can make a setToNothing method, a setToNull method wouldn't make sense. – Molly Stewart-Gallus Jun 09 '12 at 21:38
0

I am also unsure what you mean by a "maybe type"! Could a protocol be what you want with some classes implementing the protocol and others not. They you can check if objects implement it or not [yourObject conformsToProtocol:@protocol(yourProtocol)]. I hope this helps but if not some more clarification would be good.

Scott Sherwood
  • 3,108
  • 25
  • 30