Re: object type testing
Re: object type testing
- Subject: Re: object type testing
- From: Erik Buck <email@hidden>
- Date: Mon, 8 May 2006 07:41:52 -0700 (PDT)
I don't know your background and education, so forgive me in advance if my advice seems overly simplified.
Quite often, when you are reading data that is defined by a grammar, you want to use a parser that validates the grammar. Consider using flex and bison which both work well with Objective-C and are already installed on your Mac. As an alternative, you might want to write your own simple recursive descent parser in Objective-C.
How are you converting the small number of elementary data types to instances of Objective-C classes? Are you perhaps using NSNumber and NSString? As I suggested before, the type checking you seem to want is probably best handled by a lexigraphic scanner like flex. The adherence to a grammar is probably best validated by a parser.
However, I see nothing in your description of the type checking you want that precludes the use of polymorphism or requires explicit class membership testing.
How about
// Assuming mostRecentlyAcceptedObject is an instance of XObject, the following
// check give the XObject a chance to accept or reject the nextObject. If the next object is
// not a YObject, the XObject will reject it.
if(![mostRecentlyAcceptedObject doesAcceptFollowingObject:nextObject])
{
// The most recently accepted object does not accept being followed by the next object
}
else
{ // Accept nextObject and make mostRecentlyAcceptedObject = nextObject
}
The code above will work identically no matter what the class of mostRecentlyAcceptedObject is. For example, if mostRecentlyAcceptedObject is an instance of YObject, perhaps it will only accept a nextObject that is an instance of ZObject.
Now, more to the point, there is a critical concept of substitutability that you see to be rejecting. It is normally absolutely critical that any code that requires an instance of YClass also accept any instance of a subclass of YClass. For example, in the code above, assuming mostRecentlyAcceptedObject is an instance of XObject, there is no reason for the XObject to reject a next object that is an instance of MYSubclassOfYObject. If there is a reason, I would argue that your design is broken.
Next, the criteria used to accept or reject a nextObject should not be based on the class of the nextObject. It should be based on the capabilities of the next object. Use conformsToProtocol: or respondsToSelector: to determine if the nextObject is acceptable or not.
Finally, the example you gave may be contrived. I hope it is. I obviously dont know what you are trying to achieve, but my guess is that there is unlikely to be any difference between an XObject, a YObject, and a ZObject. Are they not all numbers. If so, why arent they all just instances of NSNumber or NSValue ? If I understand you correctly, it is the location of the number (as defined by the grammar) which determines whether the number is a X value or a Y value. My guess is that you are making everything over-complex by not using a proper parser, and the class of objects is almost certainly not the best way to validate a grammar.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden