[fpc-devel] Suggestion for change: Overly strict check

[Christian Iversen]

Hi all.

I was hoping there could be a discussion of a certain feature in FPC, which 
doesn't work very well for us. Ultimately, I would like to see it gone 
completely. It's a very small extra-strong syntax check, appearantly 
implemented to avoid bad code. However, it's not entirely obvious why this is 
supposed to help.

Please consider this example:

type
  tfoo = class(tbar)
  private
  public
    procedure Frob();
    procedure Wait(delay: integer);
    procedure ReadStuff(buffer: tbuffer; wait: boolean);
  end;

When declaring classes or interfaces, it is specifically checked that the 
names of methods are NOT the same as _any_ variable name of _any_ other 
method in the class. This means that the example above will NOT compile.


Now, in Delphi mode this check is not performed, and so the code above will 
compile without problems.


The reason for keeping this check, as far as I know, is that it's supposed to 
lead to better code. For instance, in the body of ReadStuff(), the 
identifier "wait" could be potentially confused between the "boolean" 
parameter, and the "procedure(delay: integer) of object;". 

At least, that's the theory. Of cours, if the parameter "wait" was a "function 
(delay: integer) of object", there could be some confusion. This is very 
rare, however - and you have to be careful anyway, because this restriction 
is not consistent: 

var
  wait: boolean;

procedure tfoo.ReadStuff(buffer: tbuffer; wait: boolean);
begin
  // In here, wait could refer either to the parameter, or the global var. 
end;

However, it's not confused with the global var, because standard scoping rules 
apply. Same as with inner functions and such. Also, if you have a unit foo, 
with a variable bar, you can use "foo.bar" to refer to that specific var. 
However, "foo.bar" could also refer to the local record "foo" with the 
field "bar". Again, standard scoping rules solve this problem without 
incident.

The _real_ problem, however, is that with these very strict checks we 
essentially only have one namespace for each class/interface. All function 
names, parameter names AND local variable names share ONE namespace, with the 
one exception that no check is performed between functions.

We have several examples where good, standard names are used for functions, 
and then cannot be used in local variables - this is even though they could 
never be confused in any realistic scenario.

We urge you to rethink the introduction of these checks. It's making it 
tremendeously difficult for us to change our code to objfpc mode, and 
removing it would not break a single line of code anywhere. We have to 
rethink quite many variable and/or function names, because many good names 
are already taken. This is, in effect, making our code quality slightly worse 
overall.

What are your thoughts on this? 

-- 
Regards,
Christian Iversen,
Ivo Steinmann