Re: Interface Builder popularity w/ Cocoa Developers
Re: Interface Builder popularity w/ Cocoa Developers
- Subject: Re: Interface Builder popularity w/ Cocoa Developers
- From: Alastair Houghton <email@hidden>
- Date: Wed, 18 Jun 2008 17:59:07 +0100
On 17 Jun 2008, at 18:14, Chris Espinosa wrote:
On Jun 17, 2008, at 4:25 AM, Laurence Harris <email@hidden> wrote:
I really don't want to start another discussion about Carbon,
That's good, because this is not a place to beat dead horses.
I wonder how many languages that idiom works in, and how many people
as a result now think that you're some sort of horse-beating monster :-)
Try as I might, I haven't found a way to implement features in Xcode
that insulate developers from the risks inherent in developing
software on pre-release OS versions that are subject to change,
though I'm open to ideas. (We've looked at using refactoring to
migrate off of deprecated APIs but the cases are so disparate that
most mechanical solutions are inadequate).
The existing mechanism that causes GCC to emit warnings about
deprecated APIs is already a huge leap forward by comparison to most
other development environments I've used.
FWIW I don't think there is ever going to be a good fully general
solution to the problem you describe (automatically removing uses of
deprecated APIs), because it seems logically equivalent to providing
the exact same API as the original system but using the new functions
to implement it. And the only reason to deprecate an API is to get
away from some requirement that it imposed on the system by its
design, right? i.e. if it's possible to get the exact same behaviour
then you must still be subject to the limitation (if not in the system
then in the user's program now). While you could then apply more
radical transformations to try to remove that limitation I don't see
how that could ever generalise.
It can obviously be solved in a number of specific instances though,
so perhaps it's possible to provide a general solution to a useful
subset of all possible deprecation scenarios?
Incidentally a related (but different) problem is that of having to
use SPIs on earlier versions of OS X to get behaviour that's exposed
via APIs on later builds. Some people may be able to write all their
apps for Leopard, but sadly not all of us can do that straight away,
and the kind of technology you're talking about might be able to help
migrate away from SPIs when that eventually changes. (I'm aware that
SPI use is discouraged, but e.g. DiskArbitration is an SPI on 10.3, in
spite of being a particularly useful framework for some of us... in
fact, it was SPI on 10.2 and worked radically differently if I
remember rightly, which serves as a cautionary tale for people using
SPIs and expecting not to get burned.)
It might even be interesting to add something to Xcode so that Apple
can get aggregate statistics on API/SPI usage by third party
developers to drive development of automatic deprecation removal
solutions.
Whatever, if this turns up in a future Xcode (even a good *partial*
solution), I'll be dead impressed.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden