[lazarus] Name Confilct in fpc

[Michael Van Canneyt]

On Mon, 28 Feb 2000, Peter Dyson wrote:

> 
> ----- Original Message ----- 
> From: Marc Weustink <Marc.Weustink at cuperus.nl>
> > 
> > BTW. Have you tried this in delphi ?
> > 
> > Marc
> > 
> The code works in Delphi... it was a problem I came across trying
> to convert some working delphi code mwCustomEdit 92a suite of
> components that I had sucsessfully compiled and installed into D5.
> 
> Not tried it in D4 yet but will try to do that later!
> The code given was just a simpler example of the problem.
> It seems that Delphi will find a mismatch in the calling convention 
> in the current namespace scope, and then  look for the same name
> in a higher namespace until it finds a match.
> 
> The other thing I found after this which Delphi will happily handle 
> but which fpc throws up on.....   
> 
> type
>   TSomeObject = class(TObject)
>   private
>     FSomeVar: TSomeType;
>     ........
>   public
>     procedure DontWork(Dummy: String; SomeVar: TSomeType);
>     procedure ......
>   published
>     property SomeVar: TSomeType Read FSomeVar; 
>   end;
> 
> The Fix is easy...
> 
> procedure DontWork(Dummy: String; aSomeVar: TSomeType);

This is done deliberately. We feel that having the same name in a
parameter of a method and a property name is very bad coding and
should not be allowed. This is, of course, debatable since you could
e.g. argue that the procedure starts a new scope, and that within
this scope you can redefine any symbol etc etc etc...

Probably we'll make some compatibility switch, but don't count
on it for the near future.

> 
> but when working with code such as the mwCustomEdit and trying to 
> keep it so that the sources will compile under delphi and fpc
> {$IFDEF MWE_FPC}a{$ENDIF}SomeVar gets a bit ugly as
> I am trying to keep track of what changes I make, and not just 
> 'fix' it, as it records the problems encountered in porting delphi
> code.
> 
> This seems to also be a namespace related problem. I am only 
> guessing, but I think the compiler must keep a list of single names
> unless they have been flagged as overloaded, a local encounter
> of a name replaces a more global name and the compiler can no 
> longer resolve the higher namespace variable.
> 
> Ok while on the workings of the compiler, another question...
> As the compiler seems to have an internal method of translating
> SysUtils to SysLinux, is there any mechanism to be able to 
> instruct the compiler to translate user space unit names..
> the obvious example of course Windows -> LclLinux. or even
> LclInt -> gtkInt | kdeInt. The use of an itermediate object to do
> desktop environments would then be deprecated.

The compiler doesn't translate sysutils to syslinux.
Where did you get that ? syslinux is the system unit on linux;
(The compiler has an internal list of what the system unit is named
like on a particular OS.)

No translation of unit names is done. As an aside; the unit aliases
in Delphi are buggy, and you can easily crash Delphi by using them.
We have no plans for implementing them as well.

Michael.