Difference between revisions of "FPC PasCocoa"

From Lazarus wiki
Jump to navigationJump to search
(New page: todo: create a wiki page documenting how the syntax should look, and mentioning any kind of special things to take into account, such as a) how to declare a constant NSString/CFString i...)
 
m
Line 1: Line 1:
 
 
todo:  
 
todo:  
  
Line 12: Line 11:
 
***
 
***
 
c) probably many more things I'm currently not thinking of
 
c) probably many more things I'm currently not thinking of
 
 
orrection: where everything can be an object. And that's not even inherently bad, as long as the run time environment (be it a static or a JIT compiler) can "unbox" the values in cases where performance matters (as is done extensively in the latest crop of highly improved JavaScript engines). It certainly makes all sorts of introspection code more powerful useful (can introspect everything) and simpler (no special cases). Note that this does not hold for Java, as it also has e.g. plain int and float types.
 
 
Anyway, wrapping a class around an integer is not really comparable. Delphi-style Pascal already contains similar functionality with delegates via the "implements" keyword (then you can also delegate methods of a class to some member). But maybe that would be a better syntactical approach if this functionality is desired. It also solves the constructor problem (since then you are explicitly responsible for constructing the ObjC class, as it will be a plain field)
 

Revision as of 00:11, 6 March 2009

todo:

create a wiki page documenting how the syntax should look, and mentioning any kind of special things to take into account, such as 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