Hello,

I am having trouble with the delphi mode and objective pascal. If I use this defines:

{$mode delphi}{$modeswitch objectivec1}

Then I get an error in this line:

  MainWindow.contentView.addSubview(TextField);
simpleform.lpr(63,26) Error: Unknown record field identifier "ADDSUBVIEW"

And in this one too:

  NSApp.run;
simpleform.lpr(71,9) Error: Unknown record field identifier "RUN"

If I use

{$mode objfpc}{$modeswitch objectivec1}

then everything builds fine.

Also, some more things:

Is creating the autorelease pool necessary or will the compiler do it automatically? I see that it isn't created in some examples which use NSApplicationMain, and in the docs of this routine It's never said that it will create the autorelease pool.

Also, should I initialize NSApp or just use the default? I remember that one needed to initialize it in PasCocoa with:

  NSApp := NSApplication.sharedApplication;

thanks,

Please file a bug report with a small, compilable self-contained example.

Also, some more things: Is creating the autorelease pool necessary or will the compiler do it automatically?

autorelease pools are not part of the language, they are part of the Cocoa framework. The compiler never automatically creates them.

I see that it isn't created in some examples which use NSApplicationMain, and in the docs of this routine It's never said that it will create the autorelease pool.

From http://developer.apple.com/Mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSApplication_Class/Reference/Reference.html#/ /apple_ref/doc/uid/20000012-800060, last paragraph of "Overview" :

"The NSApplication class sets up autorelease pools (instances of the NSAutoreleasePool class) during initialization and inside the event loop—specifically, within its initialization (or sharedApplication) and run methods."

Also, should I initialize NSApp or just use the default? I remember that one needed to initialize it in PasCocoa with: NSApp := NSApplication.sharedApplication;

See again http://developer.apple.com/Mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSApplication_Class/Reference/Reference.html#/ /apple_ref/doc/uid/20000012-800060, but the first two paragraphs of "Overview".

Jonas

Thanks Jonas,

One more thing, why is the modeswitch called objectivec1 ? It could be objectivepascal instead.

Does the number 1 imply that it's version 1 of the mode and there may be multiple versions supported at the same time? Or was it for Objective C Runtime Library 1.0 ? (I am almost sure that not)

thanks,

It means/meant version one of the Objective-C language. The Objective-C language evolves semi-independently of the run time (you can write programs in Objective-C 2.0 running on i386 and ppc32, whose Objective-C runtime is version 1). Objective-C 2.0 (the language) features require Mac OS X 10.5 or later, while 1.0 features are available as of 10.0.

See http://en.wikipedia.org/wiki/Objective-C#Objective-C_2.0 and http://lists.apple.com/archives/Objc-language/2006/Aug/msg00039.html for some features that were added in 2.0. And I just realised I actually already added a feature of Objective-C 2.0, namely the ability to specify protocol methods as "optional" (although this will not break programs when running on 10.4 and earlier, because those systems only have version 1.0 of the run time, and in that case no distinction is made in the rtti between optional and required methods -- so this means that FPC takes these modifiers into account during compilation, but the run time won't see/check them when running on such systems).

That's also why it says objectivec1 and not objectivepascal1: it refers to the Objective-C 1.0 language.

Jonas

Thanks again,

one more thing, is NSDelegatesAll not being build? I am trying to use it, but the compiler cannot find the unit. Maybe it is missing from the makefiles?

thanks,

Eh ?

How can a programming language feature depend on an operating system ?

Michael.

In our previous episode, Michael Van Canneyt said:

Keep in mind you can add methods runtime in objective C. IOW a library can construct tobject differently.

Yes, but that is a run-time feature, not a language feature. The language feature states that you can add methods runtime. What you do with it is no longer a language feature, I would think ?

Michael.

Felipe Monteiro de Carvalho wrote

one more thing, is NSDelegatesAll not being build? I am trying to use it, but the compiler cannot find the unit. Maybe it is missing from the makefiles?

No. It doesn't even compile. It was added before FPC supported the objccategory keyword, to allow you to easily copy/paste category methods from that source file to your program if you needed them. There is no new version of the parser yet that properly generates the categories.

Jonas

Objective-C, being a very dynamic language, relies on support in a runtime library for several language features (even method dispatching is handled using interaction with the runtime). Mac OS X 10.4 and earlier ship with a version of the runtime library that does not support all features added in the Objective-C 2.0 language. For example, it has no RTTI support for properties or garbage collected classes (GC requires for each class a layout in the rtti that describes which fields contain strong and which contain weak references to class instances).

You could in theory build a newer version of the run time library and include that with your app, but given how dynamic linking is implemented in Mac OS X (the absolute path to a dynamic library is hardcoded in applications/libraries that use this library, in order to avoid accidentally loading a wrong/different version if it happens to be in the path), you'd probably end up with two versions of the Objective-C run time library in memory at the same time (one for your app, and one for the system libraries -- which would have exactly the same consequences as using an FPC app with an FPC library and both having their own copy of the rtl: no shared class hierarchy etc).

So you'd have to replace the system version of the Objective-C runtime library with your copy, which is kind of not-done for third party apps.

Jonas

Hello,

Do we really need the message identifier in all methods? I mean, can't the compiler just guess the name by substituting _ with : ? Then we could use message only for those cases where the string it too long for FPC to handle.

thanks,

Felipe Monteiro de Carvalho wrote

Do we really need the message identifier in all methods?

No, only for new ones. When you override methods, implement methods from protocols, or reintroduce methods via a category, you don't need it. Then the compiler knows the selector thanks to the previous declaration and can copy it from there.

I mean, can't the compiler just guess the name by substituting _ with : ?

A compiler that guesses is a bad compiler. If there is one thing that makes code error-prone or hard to read, then it's language features where you have to know how the compiler "guesses".

Jonas