FPC PasCocoa

Note: This page as well as PasCocoa compiler feature is under construction.

So if you have anything to add or have your own idea feel free to express

yourself on this page, or mailling lists.

But DO NOT erase others people's writtings.

Thank you

PasCocoa compiler's support

Compiler's PasCocoa support is a planned feature, that's not yet implemented, but discussed. Currently PasCocoa is supported as ObjFPC wrapper classes. You can learn more about it at this page PasCocoa

Using wrapper classes is generally a hard task, because it demands of the programmer some knowledge about wrappers' implementation.

For example: it must be remembered, that wrapper object should be created to use objc object . If object's "id" reference is not passed as Handle to the wrapper's constructor it should be assigned in some other way, otherwise, wrappers will not work.

Using objective-c objects can be much easier, if all the job of handling and calling objective-c methods is done by the compiler itself. It is possible, because there's objective-c runtime API available. Allowing any language to working with objective-c classes and objects.

Syntax

Class declaration

To declare an objective-c class type a keyword "objcclass" is introduced. Objective-C classes must be declared (as any other Pascal type in "type" section of the unit)

 type
   ObjCClassName =  objcclass [(ObjCSuperClassName [, ProtocolName, ProtocolName])] [external]
     [variables declarations]
     [method declarations]
   end;

objcclass - defines a obj-c class type declaration

ObjCSuperClassName - defines parent (or super) class for the class. If name is not specified, it's considered that type inherits from base obj-c class (NSObject)

external - Objective-C class declaration. It's necessary to distinguish a class that's defined by (Cocoa) framework, from the class, that's declared by user. Defines, that the type is interface declaration, and the class is implemented in the framework.

Method declaration

In general methods are declared in the same way as pascal classes are declared, with the except that each objcclass method must also have a messaging name specified:

 NSSomeObject = objcclass(NSObject)
   procedure method(params: Integer); message 'method:';
 end;

each objcclass method is followed by keyword "message", and the keyword is followed by a string constant, that defines obj-c method name.

If method name is preceeded with keyword 'class', than it means that method is objcclass method (marked as preceeding "+" at objective-c), rather than instance method (marked as preceeding "-")

Note: it's common for objective-c to start method's name in lower case letter. PasCocoa should follow the same way for objcclasses.

todo:

a) how to 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) probably many more things I'm currently not thinking of