Changes between Initial Version and Version 1 of NoteAboutCocoaVersions


Ignore:
Timestamp:
05/26/08 17:45:37 (7 years ago)
Author:
alms
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NoteAboutCocoaVersions

    v1 v1  
     1{{{ 
     2From: Gary Byers 
     3Date: May 26, 2008 4:27:29 AM EDT 
     4Subject: Re: [Openmcl-devel] Is the Cocoa bridge still tied to exactly one version of the Cocoa frameworks? 
     5 
     6On Mon, 26 May 2008, Axel Katerbau wrote: 
     7 
     8> Is the Cocoa bridge (ObjC framework brigde in general) still tied to 
     9> one specific version of the framework? 
     10> 
     11> E.g.: Will a shipped application (as a Mac app bundle) likely break 
     12> with a new version of Mac OS? 
     13 
     14No, not in general. 
     15 
     16> Some old documentation stated this but a solution to this was kind of 
     17> announced for the future. What is the state of this? 
     18 
     19Until a few years ago, the bridge's notion of what ObjC classes and 
     20methods existed was based on introspection: it asked the runtime 
     21to enumerate all classes and methods when it first started up. 
     22 
     23This generally included hundreds of classes and thousands of 
     24methods that weren't documented or described in the interfaces 
     25(e.g., private, implementation-level internal things.)  That 
     26set of things changed from dot release to dot release, so 
     27an application saved under (for instance) 10.4.8 found itself 
     28in a different world when running under 10.4.9, and there 
     29was no good way to tell whether the differences were significant 
     30or not. 
     31 
     32For the last few years, the bridge's notion of what classes and 
     33methods exist is based on what's declared in the interfaces.  This 
     34usually only changes between major OS releases and newer releases 
     35are usually supersets of older ones, so (for instance) something 
     36built using Tiger interfaces would generally run under Leopard. 
     37 
     38Some of this stuff is complicated and there are certainly things 
     39to go wrong, but it's certainly intended that: 
     40 
     41- saved Cocoa applications aren't sensitive to minor OS release 
     42  changes 
     43 
     44- saved Cocoa applications don't need access to the interface 
     45  files in order to run (though if the application is some sort 
     46  of development system, the interfaces may be needed to develop 
     47  new code.) 
     48 
     49}}}