• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: loop efficiency & messages
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: loop efficiency & messages


  • Subject: Re: loop efficiency & messages
  • From: John Stiles <email@hidden>
  • Date: Wed, 23 Mar 2005 11:07:56 -0800


On Mar 23, 2005, at 10:59 AM, Thomas Davie wrote:


On Mar 23, 2005, at 6:45 PM, John Stiles wrote:

On Mar 23, 2005, at 10:34 AM, Thomas Davie wrote:


On Mar 23, 2005, at 6:26 PM, John Stiles wrote:

On Mar 23, 2005, at 10:00 AM, Philip Mötteli wrote:

So IMHO, the reason, why KVC is looking also into the "get" version, is due to historic reasons and is definitely not good coding style. Apple might optimize this case away at any time.

Nope. Once it's documented, it isn't changing. They can't break shipping apps.

Um, no, deprecated code is free to disappear at any time. Why do you think you can't create System 7's open/save dialogs any more? It usually won't disappear because it tends to upset developers - but you should never rely on it always being there.

What?!?

Bull. Standard File went away because all of InterfaceLib went away, at the advent of OS X and Carbon. Carbonization automatically required major changes to all apps--everyone was forced to make huge updates to their codebase for the many, many updated APIs. EVERY shipping app required a rebuild to support Carbon. That's the kind of change that happens once every 20 years. Apple is not going to obsolete all known Cocoa apps for a very, very, very long time--and when they do, there will be bigger changes than this, I promise you.

No, but I would bet my bottom dollar that methods like NSTableView's selectRow:byExtendingSelection: will have disappeared a couple of major versions down the line.

Apple has very a specific policy about making changes to any public, documented API that could break any shipping app.
That policy is "we don't do it."
I haven't looked up the method you mention, but unless you are positive that no publicly released apps use it, I think your assertion is incorrect.


_______________________________________________
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


References: 
 >Re: loop efficiency & messages (From: Will Mason <email@hidden>)
 >Re: loop efficiency & messages (From: Charilaos Skiadas <email@hidden>)
 >Re: loop efficiency & messages (From: Sherm Pendley <email@hidden>)
 >Re: loop efficiency & messages (From: Charilaos Skiadas <email@hidden>)
 >Re: loop efficiency & messages (From: Philip Mötteli <email@hidden>)
 >Re: loop efficiency & messages (From: John Stiles <email@hidden>)
 >Re: loop efficiency & messages (From: Thomas Davie <email@hidden>)
 >Re: loop efficiency & messages (From: John Stiles <email@hidden>)
 >Re: loop efficiency & messages (From: Thomas Davie <email@hidden>)

  • Prev by Date: Re: Case insensitive autocomplete
  • Next by Date: Re: loop efficiency & messages
  • Previous by thread: Re: loop efficiency & messages
  • Next by thread: Re: loop efficiency & messages
  • Index(es):
    • Date
    • Thread