Talk:FPC PasCocoa

There is interest in expanding support in FPC for coding applications for the Macintosh platform which can incorporate the Cocoa framework. Some work has already been accomplished in this area and some other discussions have begun weighing potential compiler support. This wiki page is an attempt to summarize the discussions and issues surrounding the support and implementation concerns. The intent is to maintain this page as an up to date reference for open and resolved issues so avoid repetitive questions and having to wade through previous mailing list posts.

If you are able to absolutely clarify or add to anything written on this page, please go ahead and make any corrections or additions directly on this page. If you are unsure of anything, please post your thoughts or questions to the MacPascal mailing list or add them to the "Discussion" page for this article. If you think something is missing in this page, go ahead and add it as an underlined/red question and notify the mailing list of it and hopefully someone or yourself will enter the appropriate text (deleting the question from the page in the process.) If this seems to be too many guidelines they are only meant to facilitate things and keeping some semblance of order and not meant to get in the way of getting things done :) If anyone can improve the process, feel free to voice their constructive opinion :)

Everyone is welcome to participate. Thank you for your interest and support of this project.

to subscribe to the MacPascal mailing list : http://lists.sonic.net/mailman/listinfo/mac-pascal

to post a message to the mailing list : Mac-Pascal@listman.sonic.net

Goals

Can someone summarize the goals of what are (and are not) being discussed currently?

• Compiler support to make it easier and more transparent for declaring and implementing an FPC Class to map to an Objective C Class. (2.0 Bindings)

• A new RTL interface unit containing a number of basic/useful Objective C Classes (which would expand as effort permits) ***

• Interface Builder Support - NOT?

• Objective C 1.0 bindings - NOT?

• *** [[Are we talking about just implementing single calls or are we shooting for semi full framework support so one can use Cocoa event and window handling? From reading further on, it looks like we are just worrying about the programmer implementing one function at a time as needed?]]

Any more goals?

Current PasCocoa Implementation

Currently PasCocoa is supported as ObjFPC wrapper classes. You can learn more about it at this page PasCocoa

How does anything decided or implemented here affect the existing PasCocoa with Objective C 1.0 binding work?"  There seems to be a lot of good information there - what things there apply here or vice versa?

Using wrapper classes is generally difficult because it demands the programmer have some knowledge about the wrappers' implementation. For example, it must be remembered, that a wrapper object needs to be created to use Objective C object . If object's "id" reference is not passed as a Handle to the wrapper's constructor, it should be assigned in some other way, otherwise, wrappers will fail to execute properly.

Are there other specific issues which can be mentioned?

If the compiler can take care of some or all of the translation and mapping issues, implementing Objective C Classes/objects is much easier to implement. If the Objective C runtime API is available and interfaced to, it is possible for any language to work with objective-c classes and objects.

Proposed Compiler Syntax

Class declaration

To declare an FPC Class for an external objective-c class, the keyword "ObjCClass" would be introduced. Objective-C classes must be declared individually (as any other Pascal type in the interface section of the unit) Unless a new RTL unit is created? For example:

 type
   YourClassName =  ObjCClass [(ObjCSuperClassName [, ProtocolName, ProtocolName])] [external]
     [variables declarations]
     [method declarations]
   end;

ObjCClass - defines an Objective C class type declaration

ObjCSuperClassName - identifies an optional external objective C? parent (or super) class for the class. If the superclass name is not specified, it's considered that type inherits from the base objective C class, NSObject

external - Objective-C class declaration. This is necessary to distinguish a class that's implemented by an external, non FPC supplied framework or library (which is from Cocoa in this case) from regular Pascal routines implemented in an FPC user written unit . The Pascal type is declared in the interface of the unit, and the class is implemented in the external framework. Do we need to write anything in the implementation section of the unit or will this be handled automatically without having to write anything there?

Method declaration

In general, Objective C methods are declared the same way regular pascal class methods are declared. The only? exception is that each Objective C Class method must also have an additional messaging name specified. Example:

 AnotherObject = ObjCClass(NSObject)
   procedure aMethodName ( params: Integer); message 'aMethodName:';   
 end;

each ObjCClass method name is followed by keyword message, and the message keyword is followed by a string constant that matches an existing Objective C method name. So, this means, you will only be able to use a subset of all the possible methods available from the actual underlying Objective C Class = those specific methods you specifically declare?

If the method name is preceeded with keyword class, it signifies that the method is an ObjCClass method (marked as preceeding "+" at objective-c), rather than instance method (marked as preceeding "-") Need an example of this syntax. Not sure what you are saying here or how this is different than the above declaration

'Note: it's common for an objective-c method name/identifier to begin with a lower case letter. It is recommended that PasCocoa objects declared in an FPC program follow the same convention.

To D0 List:

a) how should one declare a constant NSString/CFString in Pascal (the @"somestring" from Objective-C)

b) ideas on how to deal with categories. As Gale Paeper mentioned in a mail a couple of years ago on this list:

Since class categories and protocol usages are only selectively defined and used based on the application's use of particular Cocoa frameworks, one needs to be able to restrict the declarations the compiler sees to only those declarations applicable to used frameworks. If one doesn't have a means to restrict the seen declarations, one will need to provide in some form implementing methods for every single protocol and category methods that exits in the complete Cocoa framework, I think, whether one needs to or not. (Without restricted declaration views, I also think you'll be building a class runtime support data structures which will have erroneous results in runtime test for class protocol and category support tests.) In order to provide restricted declaration views, one needs to be able to extend class type category and protocol method declarations and implementations in units other than the unit containing the base declaration for a class.

Since an all inclusive MacOSAll type of unit won't provide restricted declaration views, I think looking into providing FPC support for non-scoping uses clauses with uses propagation to support umbrella framework style units would be worthwhile. If one doesn't have uses propagation support and one needs restricted declaration views, the uses clause unit list can get pretty long. While there's nothing inherently wrong with long unit lists in uses clauses, it is quite a hassle that quite a few folks don't want to have to deal with.

c) Please add your particular issues / questions here.

Porting Objective C & Cocoa to FPC

[[---maybe a paragraph or two on how Objective C declares classes,objects and methods. And how that Objective C declaration would map to an FPC Class.

Then maybe a paragraph on the Cocoa framework and an example of a typical Cocoa class in Obj C. ?

Then some links to ObjC/Cocoa information for first time users: Need someone who knows their way around the Apple (and other) Cocoa documentation. suggestions welcome :)]]

http://developer.apple.com/documentation/Cocoa/ObjectiveCLanguage-date.html

http://developer.apple.com/referencelibrary/API_Fundamentals/Cocoa-fund-date.html

http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/WhatIsCocoa/chapter_2_section_1.html#//apple_ref/doc/uid/TP40002974-CH3

-- Then specific issues (these particular entries snipped from the MacPascal mailing list

http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html

Everyone going into Cocoa pogramming would be well served reading this guide. The Cocoa class reference is in great majority of cases silent about what you are expected to do with regards to object ownership with instances that you obtain from the system, since authors expected us to read and understand above document. Only exceptions are documented. Sorry about sounding obnoxious, but on cocoa-dev mailing list there are at least 2 threads every month about crashes or leaks, because people didn't read, or have just skimped this guide. nice reading, - Gorazd

and

For all that are working with Cocoa it is mandatory to review:

http://www.stepwise.com/Articles/Technical/2001-03-11.01.html

http://www.stepwise.com/Articles/Technical/HoldMe.html

Despite it is written in 2001, it is still a relevant document describing memory management rules and owneship of objects that are valid unless you use Objective-C garbage collection. -Gorazd