On Saturday, April 26, 2003, at 09:00 AM, Paul Davis wrote: To whom it may concern: My goal was to subclass IOBluetoothOBEXSession because I needed some unique instance variables and methods not contained in this class. There is one problem. The class method withIncomingRFCOMMChannel cannot be properly used by a subclass because it is defined as: + (IOBluetoothOBEXSession *)withIncomingRFCOMMChannel: (IOBluetoothRFCOMMChannel*) inChannel eventSelector:(SEL)inEventSelector selectorTarget:(id)inEventSelectorTarget refCon:(void *)inUserRefCon; With this definition, a subclass of IOBluetoothOBEXSession will always return the IOBluetoothOBEXSession type instead of the subclass type. It seems to me that the standard objC approach would have been to define this class method as follows: + (id)withIncomingRFCOMMChannel: (IOBluetoothRFCOMMChannel*) inChannel eventSelector:(SEL)inEventSelector selectorTarget:(id)inEventSelectorTarget refCon:(void *)inUserRefCon { id newInstance = [[[self class] alloc] init]; ....Do whatever you do to setup an OBEXSession... return [newInstance autorelease]; } This way when IOBluetoothOBEXSession is subclassed and the withIncomingRFCOMMChannel message is received by a subclass, the instance returned will be the same type as the subclass. Do you agree? Of course, I found another way to accomplish what I wanted to do. I would have liked my design better if the withIncomingRFCOMMChannel method were defined as mentioned. In theory, the IOBluetoothOBEXSession class encapsulates all of the necessary public API for an OBEX session. To that end, it shouldn't be necessary to expose your specific subclass at all. However if you do add new API, your clients will need to know that they are getting an instance of your subclass. Your best bet is to just subclass +withIncomingRFCOMMChannel:... and then cast the result to the appropriate class. In general, I'm a big fan of strongly typing return values as much as possible (i.e. returning IOBluetoothOBEXSession * instead of id). The argument is that by including the type in the return, the compiler will be much more likely to catch any programming errors since it knows more about the object. If we had returned id in that API, all clients would have had to cast the result to an appropriate type to get the benefit of the compiler's type checking instead of only the cases where a subclass had new API to expose. And in the case of +withIncomingRFCOMMChannel:..., the return type is technically correct since in your subclass, you are still returning an IOBluetoothOBEXSession *, but is also a member of your subclass as well. It may even be possible to declare your +withIncomingRFCOMMChannel:... to return your class rather than IOBluetoothOBEXSession, although I have not personally tried that approach. The compiler may complain about not being able to determine which +withIncomingRFCOMMChannel:... method to use when your client calls it. - Eric _______________________________________________ bluetooth-dev mailing list | bluetooth-dev@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.