The principle in GPC WRT dialects is that the default mode should accept all features of all dialects, and dialect options only turn off everything that doesn't belong to the given dialect. (In a few cases, there are warnings in the default mode about strange features, such as BP non-constant "typed constants" which are turned off by the dialect option.) So what you propose about the switch would be against this "policy".
Up to now, mixing the dialects has caused surpringly few problems, but there's no guarantee that this will remain so with new dialects added.
Ok, so if I understand that correctly, if there are features in CodeWarrior Pascal that can be implemented without conflicting with other dialects, that would be the sort of thing you'd want to see added. These might include:
univ (doesn't conflict as long as it is overridden by any user defined variable/type/etc)
making the "implementation begin" optional in interface only files.
What do you suggest for features that do conflict, but that are used widely in existing code?
Some tasks are best done by changing the source files, but other tasks would be much easier done with modifications to gpc to support some of the Mac constructs (eg univ untyped pointers,
I've commented on them (quite negatively ;-) recently. If I understood Adriaan's example right, they're mostly used with pointers and behave mostly like `Pointer' does in GPC/BP. (There are some subtle differences, such as Adriaan's example #3, but this is a really dangerous case, and it might be good if this doesn't work -- i.e., the programmer will be forced to check such cases and perhaps rewrite them more cleanly ...).
One of the useful places I think is for writing functions that take opaque record pointers without having to muck with casting everywhere. Eg, the interface might be:
type UserDataPtr = Pointer;
type OurData = record blah blah blah end; OurDataPtr = ^OurData
function CreateOurData( var data: univ OurDataPtr );
Then the users of the unit can use UserDataPtr and never have to worry about accidently accessing the internal records and the local unit can use the data without having to cast every input parameter.
Where it is typically used in the Mac world is for Handles (which is just a pointer to a pointer, type Handle = ^Ptr, but it's a useful type in that you can resize a Handle without breaking any references to it). So you might have:
type OurDataHandle = ^OurDataPtr;
and be able to pass it to a standard function like:
function ResizeHandle( data: univ Handle; newsize: Size ): OSError;
ResizeHandle could just have data: Pointer, but that gives less information and requires casting in ResizeHandle to access as a generic system handle. Using data: Pointer is no more or less safer than using data: univ Handle.
It is possible some of the benefits can be got using restricted records, but I don't think that works for cases where you want to write generic routines where Handle is treated something like a super class (excuse the misuse of terminology) of all Handle types.
If that's all, the perhaps just "defining away" the `univ' will do the trick (`--cidefine=univ=' on the command line if you don't want to modify the sources). I don't like macros in general, but here perhaps they're more harmless than the alternatives ...
Unfortunately, if I do this to this, then the existing code wont work since it will expect to be able to pass in arbitrary pointers. Fortunately, all uses of univ in the system interfaces are exactly "univ Ptr", and so Pointer will indeed work fine for that.
external names that match exactly the procedure names,
That's possible now with `asmname'. If you mean that, say, `procedure foobar; external;' and `procedure FooBar; external;' should behave differently -- well that's in direct contradiction to the Pascal standards (and other supported dialects such as BP), so I'd have severe issues with this one.
Yeah, I agree with the qualms on this. It would make the interfaces a heck of a lot cleaner than adding asmname for every single function. This is the sort of thing where I would use a compiler directive {$asmname-asgiven} {$asmname-lowercase} {$asmname-underscorelowercase}. It's not generally a good idea, but under certain circumstances it would simplify life, which to me sounds like a good type for a compiler directive.
some minor things like, and some major things like binary compatible "short" strings (this is a big one),
We plan to do this for BP short strings. I don't know if these are the same (first byte: Length (limited to 255) accessible as a char `StringVar[0]', then the characters, capacity not stored). If so, yes, implementing them is wanted (but indeed quite involved).
Yes, that sounds the same. I figured that would come sooner or later and was wondering whether to have a look at implementing it in gpc, but that seemed a little bit like jumping in at the deep end!
closer object modal (this is a huge amount of work, either in gpc or in porting)).
Again, I don't know what the differences are. The OOE and Delphi models (rather close, but quite different from the existing BP model) are planned (and also much work) ...
I don't know the details of how exactly they differ, but for starters in THINK/CodeWarrior:
All methods are virtual
Overriding a method requires the use of the override keyword (ie procedure method1; override;) I see GPC's docs have override listed but not what it does.
All objects are pointers, and have to be newed and are implicitly dereferenced (actually, they are either pointers or handles, but since they are implicitly dereferenced, the user doesn't need to know which). eg:
var o: MyObject; begin new(o); o.Method1( 1 );
In terms of converting existing Mac code across to GPC's object model, the best I can think of is to add "virtual" to every method, deal with the object/pointer difference by making a pointer type for each object, and then adding an explicit indirection for each use of the object. However automating that would be rather challenging I think. And alternative might be a GPC switch to emulate the Mac style objects. It's a toss up which would be more doable. Either way it needs more thought and isn't necessary to get to stage 2 (stage 1 being gpc working under Mac OS X which Adriaan already has largely done, stage 2 being to be able to use the Mac interfaces to write arbitrary Mac code and stage 3 being to enable porting of existing Mac code to gpc).
Anyway, this is probably longer than anyone wants to read, I'll go back to trying to parse the Mac Universal Interfaces into something GPC is happy with so we can at least reasonably get to stage 2 and avoid having to generate any more CodeWarrior code that is incompatible with the generally much nicer GPC language.
Thanks, Peter.