views:

157

answers:

2

I'm writing some code that is wrapping up some CFNetwork stuff to do DNS resolution in Objective-C.

Everything is fine and it's working, but I have a few questions:

The callback function prototype for CFHost's asynchronous resolution is passing references to CFStreamError structures even though the documentation says CFStreamError is deprecated and CFReadStreamCopyError should be used instead, which will return a CFError struct.

The callback function is declared as such:

typedef void (CFHostClientCallBack) (
    CFHostRef theHost,
    CFHostInfoType typeInfo,
    const CFStreamError *error,
    void *info);

There doesn't seem to be any alternative to this callback that uses non-deprecated APIs.

I thought the point of deprecating API's was that new ones were introduced that supersede the older ones? If this is true, why isn't there an alternative callback to this one that makes use of the CFReadStreamCopyError function?

The main problem I'm having that CFStreamErrors are really nondescript... Is there anything I can do to turn a CFStreamError into a CFError?


Just to clarify a few points:

I don't believe I've misread the documentation on this point. the callback method used in CFHosts asynchronous resolution system passes in a CFStreamError. While CFStreamError itself may not be deprecated, the functions that return them, namely CFReadStreamGetError and CFWriteStreamGetError are deprecated. The documentation suggests using CFReadStreamCopyError and CFWriteStreamCopyError which return CFError instead of CFStreamError.

I am wrapping this code in Objective-C and I'm making a lot of use of Foundation objects. as such, CFError is a lot more useful to me than CFStreamError is because it's toll-free bridged with NSError and CFStreamErrors don't contain nearly as much useful information as a CFError does. Further, I'm not even dealing with a CFStream directly, so why should I have to deal with its specific error struct? Finally, I want to ultimately return an NSError in a delegate call back in my wrapper class.

Also, I know that deprecation doesn't instantly mean the method is gone, but if something is marked as deprecated, it would make sense (to me at least) to provide an alternative. Otherwise, the deprecated method/function/class etc, is still being used and there's no point in deprecating it until something supersedes it?

A: 

Deprecated means it is planned to become obsolete. This is meant for Apple's software engineers as well as third-party software developers.

Also, you are misreading the documentation. The struct is returned by the function CFReadStreamGetError. The documentation is suggesting new API functions to use, not a new error struct to use.

ExitToShell
I didn't misread the docs. The wording in my question, however, is probably not the best. When I said that `CFReadStreamGetError` should be used instead of `CFStreamError`, I meant in general, instead of using `CFStreamError`s, one should use the structs returned by `CFReadStreamGetError`. But that's besides the point. The callback I'm using explicitly passes a `CFStreamError` and there is no `CFStream` for me to use `CFReadStreamGetError` on to get a non-deprecated error struct.
Jasarien
A: 

The CFStreamError struct is not actually deprecated. From the documentation, it looks like it will be in the next release (since they're deprecating methods that return it). For now, however, it looks like you will still have to deal with the struct itself, as no replacement callback has been made.

I realize this isn't the type of answer you were looking for, but the CFStreamError really hasn't been fully deprecated yet, so you won't have replacements for all uses of it.

bobDevil
Ok, well in that case, there doesn't seem to be much I can do.
Jasarien