• 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: @property problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: @property problem


  • Subject: Re: @property problem
  • From: Jim Correia <email@hidden>
  • Date: Sun, 17 Feb 2008 12:13:25 -0500

On Feb 17, 2008, at 11:59 AM, William Squires wrote:

But it doesn't answer the question. Why even make the change in the 64-bit runtime? This would seem to hide a source of bugs, by taking the responsibility for providing storage away from the programmer. Some storage is still necessary.

As it stands, you cannot add iVars to a base class in the 32-bit runtime without required that all subclasses be recompiled.


This is particularly important for frameworks like AppKit. An AppKit class cannot have an iVar added to it because it would break binary compatibility with everyone who subclassed it. The 64-bit runtime solves this problem.

And besides, in order to take advantage of Leopard features like this one (whether on PPC or Intel), you should still have to link against the 10.5 SDK, so it would seem more reasonable to make the update to both the 32 and 64-bit runtimes, but only in the 10.5 SDK. Then you could update the 10.5 SDK (to 10.5.1) to allow for this "syntactic sugar" under both 32- and 64-bit.
I mean, after all, all it means is that you're changing the default size of an (Integer) register in the CPU chip, and updating the OS to take advantage. How would this make implementing (or not implementing) this change any harder or easier?

The 32-bit runtime must remain binary compatible with all code that was compiled and targeted for Tiger and earlier.


It is extremely desirable to be able to link against the 10.5 SDK and still deploy your application on Tiger (after taking appropriate measures.)

By restricting this changes to the 64-bit runtime, all binary compatibility issues are avoided, because there are no legacy 64-bit applications.

Jim
_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: @property problem
      • From: William Squires <email@hidden>
References: 
 >@property problem (From: Randall Meadows <email@hidden>)
 >Re: @property problem (From: Joshua Emmons <email@hidden>)
 >Re: @property problem (From: William Squires <email@hidden>)
 >Re: @property problem (From: Jean-Daniel Dupas <email@hidden>)
 >Re: @property problem (From: William Squires <email@hidden>)

  • Prev by Date: Re: @property problem
  • Next by Date: Re: A couple questions relevant to games
  • Previous by thread: Re: @property problem
  • Next by thread: Re: @property problem
  • Index(es):
    • Date
    • Thread