Waldek Hebisch wrote:
Adriaan van Os wrote:
There is another problem, probably related to qualified identifiers.
In the GNU Pascal Interfaces for Mac OS X, based on Apple's PInterfaces, we have a unit CGError. It defines a type CGError (a signed 32-bit integer).
unit CGError; interface .... uses MacTypes,CGBase; .... type CGError = SInt32;
We probably should warn here that the type will usually be shadowed by unit name.
But what if a type T is defined in another unit, independent of a unit T with the same name ? Then it might be a bit difficult to issue a warning.
Consider:
type rt = record CGError : integer end; var CGError : rt; i : integer; rv : rt;
then the compiler accepts:
rv := CGError; i := CGError.CGError;but rejects:
i := CGError;
Imagine now that `CGError' variable is defined in `CGError' unit. What does it mean then:
i := CGError.CGError;
Is it record `CGError' form unit `CGError' or is it field `CGError' from the `CGError' record?
Hm, yes, that is a problem, so I guess there is no other solution than changing the interface names. Peter ? Gale ? I thought about a command-line switch --no-qualified-identifiers, but even if there were such an option, we would like the interfaces to compile with programs that have qualified identifiers enabled, don't we ?
By the way, does Apple Pascal support qualified identifiers?
MPW Pascal and Think Pascal don't. MW Pascal does so (according to the docs) but in reality it only supports "System.xxx" to differentiate between a built-in runtime routine "xxx" and another routine "xxx".
Best regards,
Adriaan van Os