Changes between Version 2 and Version 3 of ObjectiveC


Ignore:
Timestamp:
Jan 13, 2009 5:51:08 AM (7 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ObjectiveC

    v2 v3  
    99=== Consequences of the goals ===
    1010
    11 We need to be able to subclass Objective-C classes (and in that process overwrite methods, add new class and instance methods, and add properties).  We
    12 might be able to get away with only supporting properties (and not ivars that are directly read and written).
     11We need to be able to subclass Objective-C classes (and in that process overwrite methods, add new class and instance methods, and add properties).  We only directly support properties with setter and getter methods and not direct access to ivars; although, the latter can be gained by using the standard C FFI.
    1312
    1413=== Pragmatics ===
    1514
    16 As far as the use of Haskell code from Objective-C goes, we can imagine two kinds of implementations: (1) We can make everything fully dynamic through the ObjC runtime at app runtime or (2) we can generate `.h` files and .m stubs statically during app compile time (from within GHC).
     15As far as the use of Haskell code from Objective-C goes, we can imagine three kinds of implementations: (1) We can make everything fully dynamic through the ObjC runtime at application runtime or (2) we can generate `.m` stubs statically during application compile time (from within GHC), and (3) we can directly generate object files that adhere to the conventions for ObjC object files.
    1716
    18 I am guessing that (1) is easier to implement and (2) more efficient.  We should try to develop a spec that allows both implementations (in that both types of implementations can be fully compliant).  Then, we can start with (1) and later move to (2) if we feel it is worthwhile – get's us a running system more quickly.
     17Option (1) has the disadvantage that all class initialisation code needs to be executed after the program has loaded and before any other code runs.  We need to arrange that for dynamically loaded objects, too.  Option (2) and (3) lead to a similar outcomes (in terms of object files), but Option (2) seems easier to implement and has some precedent in the C stubs generated for Haskell functions dynamically exported to C.
    1918
    20 Even with Option (1), where the actual class definition is dynamic, we can still provide (manually written) Objective-C header files that give class interfaces.  This enables the Objective-C compiler to do type checking and should enable the use of classes implemented in Haskell in Interface Builder.  (With Option (2), these header files should be generated by GHC.)
     19We require the programmer to supply headers for all Objective-C classes implemented in Haskell.  This enables the Objective-C compiler to do type checking and enables Interface Builder to recognises properties used as outlets.
    2120
    2221== Subtopics ==
     
    3231
    3332Chicken scheme objc egg: [http://chicken.wiki.br/objc]
     33
     34== Development team ==
     35
     36 * [http://www.cse.unsw.edu.au/~chak/ Manuel M. T. Chakravarty]
     37 * [http://algorithm.com.au/ André Pang]