+ From: Peter Dyson

+ From: Marc Weustink
+ >
+ > 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.

Yuck. I don't like this kind of behaviour. Before you know you'll end up with the most unpredictable code you've seen.

Marc

Exact, since the Insert() method of Nested is assumed.

Of course this won't compile, since the insert is located in system, and not in sysutils...

I think you would find the same problems in Delphi. The number of times I've use Insert(), Copy() and Assign() inside a form method, and got a complaint, is close to infinity.

Michael.

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.

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.

But this would also apply for methods and fields but parameters can't have the same name as methods and fields.

I have been playing with lazarus trying to get the mwCustomEdit .92a to compile.
This has lots of optimizations as far as font and other resource caches which will
probably go a long way to solving the speed, but while doing the compile/comment
out/create new methods cycle, I came across this name conflict I cannot resolve.

Here is a code snippet which shows the problem,
Along with the errors generated.
It would seem the compiler has some scoping issues. Is this design or a 'feature'? :)

The code should describe the problem clearly.

{

$Author: peter $
$Revision: 1.1 $
$Log: hello.pp,v $
Revision 1.1 2000/02/28 02:04:58 peter
Initial revision

}
unit hello;
{$mode objfpc}   file://tried delphi mode too
interface
uses SysUtils;
type
  TSomeObject = class(TObject)
  private
    s, t, v: string;
  public
    //note made sure this is not same calling convention as Insert
    procedure Insert(Dummy, Dummy1: String);
    procedure NestProc;
  end;
implementation
procedure TSomeObject.Insert(Dummy, Dummy1: String);
begin
 writeln('Hello World Again this is yet another test');
end;
procedure TSomeObject.NestProc;
  procedure Nested;
  begin
       s := 'A bit of text';
       t := ' new';
       Insert(t, s, 5); // won't compile
       //error "hello.pp" 41 Wrong amount of parameters specified
  end;
begin
       s := 'A bit of text';
       t := ' new';
       SysUtils.Insert(t, s, 5); // won't compile
       //error "hello.pp 48 Identifier not found INSERT
  writeln('Hello World Again this is yet another test');
end;
end.

I dont sea why this shouln't be allowed since there's no realy conflic. When there are a parameter which have the same name of a property or variable member those 2 simple rules apply inside the methode.

1. When using the name alone it refer to the parameter
2. When the name is preceding with 'Self' keyword + '.' , it refer to the property or variable member.

Sea exemple:

procedure TSomeObject.DontWork(Dummy: String; SomeVar: TSomeType);
Begin
  Somethink := SomeVar;      // SomeVar = Parameter
  Somethink := Self.SomeVar; // SomeVar = Property of TSomeObject
And;

There's no such ambiguity and why whould it need such restriction?

My $0.02

Vital Tremblay

--- Michael Van Canneyt
wrote:
[...snip...]

This is disappointing to hear. I don't believe the compiler should force good programming practice. In a sense you're creating a new language by doing this. I feel that FPC should be fully Object Pascal compliant. It may be a good idea to have a flag which turns on the strict coding rules (ie. the default would be like Delphi). However, I would favour a "HINT" or
"WARNING" generated by the compiler to let you know you're doing something bad. I usually compile my apps in Delphi and make sure that I get rid of all of the "HINTS" and "WARNINGS". Just my 2c.

Cheers,
Kevin.
__________________________________________________ Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

----- Original Message -----
From: Marc Weustink

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);

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.

Enough ramblings for now gotta get back to work..

peter

The compiler doesn't decide anything. The compiler programmers do :-)

Seriously; one of the reasons we ask that you use the @ when assigning procedural variables, is that we think that is more clear and exact.

This decision is of similar nature. There aren't any specifications for it; since it isn't ISO pascal, so it's pretty much up to us to decide what should and what should not be allowed.

Anyway, the discussion is largely academic, since for compatibility reasons, we'll have to implement it under the {$mode Delphi} directive.

Michael.

+ From: ]On
+
+ > 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...

Thats one of the pascal language features. I think it is not up to the compiler to decide what is a bad coding practice. What do think of:

procedure X;
var
  I: integer;
  procedure X;
  var
    I: integer;
    procedure X;
    var
      I: integer;
    begin
      //  ... do something ...
    end;
  begin
    //  ... do something ...
    X;
  end;
begin
  //  ... do something ...
  X;
end;

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

Hmmm....

Marc

+ From: Peter Dyson
+
+ .... but while doing the compile/comment out/create new
+ methods cycle, I came across this name conflict I cannot
+ resolve.
+
+ Here is a code snippet which shows the problem,
+ Along with the errors generated.
+ It would seem the compiler has some scoping issues.
+ Is this design or a 'feature'? :)

This is as far as I can see normal compiler behaviour.

+ The code should describe the problem clearly.
+
+ {
+
+ $Author: peter $
+ $Revision: 1.1 $
+ $Log: hello.pp,v $
+ Revision 1.1 2000/02/28 02:04:58 peter
+ Initial revision
+
+ }
+ unit hello;
+
+ {$mode objfpc} file://tried delphi mode too
+ interface
+
+ uses SysUtils;
+
+
+ type
+ TSomeObject = class(TObject)
+ private
+ s, t, v: string;
+ public
+ //note made sure this is not same calling convention as Insert
+ procedure Insert(Dummy, Dummy1: String);
+ procedure NestProc;
+ end;
+
+ implementation
+
+ procedure TSomeObject.Insert(Dummy, Dummy1: String);
+ begin
+ writeln('Hello World Again this is yet another test');
+ end;
+
+ procedure TSomeObject.NestProc;
+
+ procedure Nested;
+ begin
+ s := 'A bit of text';
+ t := ' new';
+ Insert(t, s, 5); // won't compile
+ //error "hello.pp" 41 Wrong amount of parameters specified

This is by design. The nearest insert takes 2 arguments.

+   end;
+
+ begin
+        s := 'A bit of text';
+        t := ' new';
+        SysUtils.Insert(t, s, 5); // won't compile
+        //error "hello.pp 48 Identifier not found INSERT

This is also by design since Insert is part of the System unit and the compiler can't resolve SysUtils.Insert. System.Insert should work here ;-)

+
+ writeln('Hello World Again this is yet another test'); +
+ end;
+
+ end.

BTW. Have you tried this in delphi ?

Marc