Nothing more to say about it, since I see we are in total agreement.
- I will produce a diff file or the changes in the Universal PInterfaces.
- If I ever submit any change to the MacPas wiki page, I will do it as a registered user.
- I will update the Xcode-FreePascal site soon with the latest development.
Thank you very much Olle and Jonas.
Best regards
Rolf
Am 16.08.2004 um 13:50 schrieb Olle Raab:
04-08-16 10.31, skrev Dr. Rolf Jansen följande:
I am with you to keep the number of changes to the PInterfaces as small
as possible. However, I would like to make a distinction between buggy
or misleading parts of the PInterfaces and those parts which simply
belong to another flavour (presumably the Mac one).
A. I advocate for debugging the UI´s and not to accommodate for bugs in the Free Pascal mode -Mmacpas.
I do not either want to accomodate for bugs.
My idea is to make fpc in mode macpas emulate Metrowerks Pascal, since this
is the most modern commercial pascal compiler for mac. And the compiler
today's active pascal programmers uses. Mode macpas should accomodate for
Think Pascal features.
And the Delphi mode of fpc sometimes support things in Delphi which is not
so nice, but not neccesarily bugs, because it should be possible to share
code between FPC and Delphi.
That said, we should of course not support all bad things in Metrowerks.
And perhaps it is good to be conservative and not implement everything right
now, at least not today :)
B. I advocate for improving the Free Pascal mode -Mmacpas in order to allow all Pascal Mac developers a smooth transition.
C. I advocate for maintaining and improving the PInterfaces as time goes by since Apple will not do it anymore.
Examples for A:
IMHO the active LongDouble routines in fp.p and the use of the term "object" at several places belong definitely to category A. In fact, your example "SetDeskCPat" is deactivated with the {$IFC CALL_NOT_IN_CARBON} directive.
Sorry, you are right.
IT IS the policy of the UI to
activate/deactivate not used parts for different platforms/targets - by
this way the interfaces became universal.
But this one:
{ * ScrollWindowRect() * * Availability: * Non-Carbon CFM: not available * CarbonLib: in CarbonLib 1.0 and later * Mac OS X: in version 10.0 or later }
is not deactivated for Non-Carbon CFM. I guess non-carbon calls is
deactivated, but not everything is properly deactivated, it is instead left
to the linker to complain about.
But ok, at least non carbon code should be deactivated under carbon.
I doubt that the term LongDouble was ever used by Mac Pascal Programmers. LongDouble was known as extended. So, I suggest not to care about the LongDouble routines, but simply deactivate them for Mac OS X by encapsulating them with the conditional directive {$IFC TARGET_CPU_PPC AND NOT TARGET_API_MAC_OSX}.
OK.
But I will anyway add LongDouble for non Mac OS X. Because it is defined by
Metrowerks.
I consider "object" to be a reserved word for Mac Pascal. So it is a
bug to use it as record field names or in routine declarations as
parameter names. There is no other way, "object" must be renamed in the
UI´s.
Metrowerks do not treat object as an reserved word, thats why this bug is
not discovered. But I agree it is not nice. So rename.
Example for B:
{$LibExport+} belongs definitely to category B. It might be a good idea
to let Free Pascal accept this directive in -Mmacpas in the future,
even if it does nothing special but simply ignor it.
OK, its added to the cvs. Its recognized but does nothing.
Example for C:
The changes to the type declaration of CStringPtr/ConstCStringPtr from Ptr to PChar belong to category C. After thinking about it, I aggree with you that this more specific change is better compared to the more general change of Ptr from ^SInt8 to PChar.
It might be a good idea to surround changes of category C with the conditional compiler directive {$IFC NOT UNDEFINED FPC}.
This would mean in the given case that in MacTypes.p:
CStringPtr = Ptr; CStringPtrPtr = ^CStringPtr; ConstCStringPtr = Ptr; ConstCStringPtrPtr = ^ConstCStringPtr;
should be changed to:
{$IFC UNDEFINED FPC} CStringPtr = Ptr; {$ELSEC} CStringPtr = PChar; {$ENDC} CStringPtrPtr = ^CStringPtr; ConstCStringPtr = CStringPtr; ConstCStringPtrPtr = ^ConstCStringPtr;
If we follow these rules then no change of either category will break compatibility to old Mac compilers or different targets.
OK.
I aggree with you that it would be great if Apple would allow us to distribute a patched version of the PInterfaces. In the meantime we have to go the diff and patch way.
In any case it is nice to have a diff file as a document of the changes.
Olle
BTW If you write in the wiki, consider to register as a user, it is then
easier to see who has written what, and to discuss that.
_______________________________________________ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
__ InstantWare ______________________________________________________ Dr. Rolf Jansen * Stephanienstraße 19 * D-76133 Karlsruhe * Germany
http://InstantWare.bei.t-online.de/ _____________________________________________________________________
_______________________________________________ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
