[fpc-pascal] cocoa programming without objective-pascal mode

[Sven Barth]

Am 03.11.2014 09:02 schrieb "Bee" <bee.ography at gmail.com>:
> On Mon, Nov 3, 2014 at 1:45 PM, Sven Barth <pascaldragon at googlemail.com>
wrote:
>>
>>
>> That's because FireMonkey abstracts all those APIs for you. The LCL by
Lazarus has the same target: no matter whether you are on Win32/64, GTK,
Qt, Carbon, Cocoa, whatever you get the same set of APIs (the API provided
by the LCL) and you don't (normally; bugs not withstanding) need to care
about platform differences.
>
>
> FireMonkey isn't native UI. It's custom drawn UI controls (based on
OpenGL?). That's why I left Delphi. I don't like non-native UI, except for
games.

The "non-native UI" aspect isn't what's the point here. It uses
nevertheless the native API (WinAPI on Windows, Cocoa on Mac OS X, etc.)
and presents you with an abstract API that allows you to use the same code
(more or less) on all supported platforms. It's the same for the LCL, but
here with native controls (mostly).

>>
>> Even if you'd directly access Cocoa using Object Pascal means you would
not be compatible with Object Pascal codes on other platforms. The same is
true for Delphi by the way. They interface with Cocoa code using COM
interfaces which are not used on the Windows platform (for this purpose).
Two different API sets!
>
>
> Why would that be? A pascal TStringList can be a NSStringArray on Cocoa,
or regular list of strings on Windows. I don't care as long as my pascal
TStringList behaves consistently on any platforms. What I do care is if I
can use TStringList on Windows, but I'm forced to use NSStringList on OSX
for the same purpose and function. I don't want that. That's why I don't
like objective-pascal dialect. *btw, the class names are just pseudo class,
you should get the point* :)

No, a TStringList can't be a NSStringArray, because they have different
functionality. The same is true for whatever other platform specific class
or functionality you pick. And somewhere there must be tee abstraction if
one wants to share code. In case of Objective Pascal you need to have
Object Pascal code that uses the Objective Pascal classes.

>>
>> Also using Objective Pascal does in no way mean that you can not use
Object Pascal. You can mix them as you want and you can use Objective
Pascal classes in Object Pascal code and vice versa (otherwise this feature
would be rather useless).
>
>
> Oh, really? I didn't know that. So, I could use objective-pascal mode on
Windows too? Including its protocol and messaging mechanism?

In theory it would be possible, because there exists a criss platform port
of the Objective C runtime, but that is currently not supported, because
noone had the need for it yet.
But that's not what I meant. The point is: on Mac OS X the classes provided
by Objective Pascal are the "system API", on Windows it's the WinAPI. They
are different API and it's not the compiler's job to abstract this, but of
the runtime library (for low-level functionality) or the GUI library (in
our case LCL or fpGui).
If you access the Objective C API manually you are basically interfacing a
C API which you wrap using Object Pascal objects. So why not instead have
these Object Pascal classes wrap the Objective Pascal classes? Because then
you don't have to worry to correctly interface with the Objective C
runtime, because the compiler does the job for you. Otherwise you need to
do all this manually which is error prone.

>>
>> So please use Objective Pascal. It will save you from quite some trouble
to implement the APIs manually (afterall there is a reason why we
implemented Objective Pascal).
>
>
> Of course there is a reason for objective pascal existence. But should I
use it? I don't know. Unless you can give me guarantee that
objective-pascal dialect can be used on Windows and Linux as well. But if
it does, why do we bother to have objective pascal at the first place? :D

I'm not giving you a guarantee, because that's not the purpose of the
Objective Pascal dialect. It's purpose is to efficiently interface with Mac
OS X's API like Delphi Interfaces were originally to efficiently interface
with COM classes on Windows.

>
> FYI, just as food for thought... I'm now considering to use RemObject's
Oxygene (another pascal variant) as it behaves almost like the way I want.
I could use the same consistent syntax on any platforms. Although I have to
know special cases where API on particular OS is very much different from
other OSes. But it's pretty rare cases. If you want to know the concept of
the language, please refer to this site:
http://www.elementswiki.com/en/Oxygene_Language

You may have the same language, but you nevertheless need to write
different code, because .Net, Objective C and Java all have different
restrictions and the base types are named differently.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20141103/67d2c646/attachment.html>