duplicate identifier

[ASerge]

Maybe the directive {$modeswitch duplicatelocals} can help somehow?

Yes, that modeswitch controls that and is enabled by default in mode Delphi.

But in {$MODE OBJFPC} the error appears, regardless of {$MODESWITCH DUPLICATELOCALS}:

Code: Pascal  [Select][+][-]

1. {$MODE OBJFPC}
2. {$MODESWITCH DUPLICATELOCALS}
3.  
4. type
5.   TSome = class
6.     procedure Proc1;
7.     procedure Proc2;
8.   end;
9.  
10. procedure TSome.Proc1;
11. begin
12. end;
13.  
14. procedure TSome.Proc2;
15.  
16.   procedure Proc1;
17.   begin
18.   end;
19.  
20. begin
21. end;
22.  
23. begin
24. end.

Code: Text  [Select][+][-]

1. project1.lpr(16,13) Error: Duplicate identifier "Proc1"
2. project1.lpr(16,18) Hint: Identifier already defined in unit PROGRAM: project1.lpr at line 6

[440bx]

But in {$MODE OBJFPC} the error appears, regardless of {$MODESWITCH DUPLICATELOCALS}:

Inconsistencies are consistently "deficient" ideas.  In the following code:

Code: Pascal  [Select][+][-]

1. {$MODE OBJFPC}
2.  
3. {$MODESWITCH DUPLICATELOCALS}
4. {$MODESWITCH ADVANCEDRECORDS}
5.  
6. program DuplicateIdentifier;
7.  
8. type
9.   TSome = record
10.     FieldA    : integer;
11.     FieldB    : integer;
12.  
13.  
14.     procedure Proc1;
15.     procedure Proc2;
16.     procedure Proc4;
17.   end;
18.  
19. procedure TSome.Proc1;
20. begin
21. end;
22.  
23. procedure TSome.Proc2;
24.  
25.   (*
26.   procedure Proc1;   { Proc1 is NOT ok here }
27.   begin
28.   end;
29.   *)
30.  
31.   (*
32.   procedure Proc2;   { Proc2 is NOT ok here }
33.   begin
34.   end;
35.   *)
36.  
37.   procedure Proc3;
38.  
39.     { but all the duplicates you can eat here, bon appetit }
40.  
41.     procedure Proc1;   { Proc1 is ok here   }
42.     begin
43.     end;
44.  
45.     procedure Proc2;   { and so is Proc2    }
46.     begin
47.     end;
48.  
49.     procedure Proc3;
50.  
51.       procedure Proc3;
52.  
53.         procedure Proc4;  { have another Proc4 for dessert }
54.  
55.           procedure FieldA();
56.           begin
57.           end;
58.  
59.         begin
60.         end;
61.  
62.       begin
63.         Proc4(); { which Proc4 gets called ? }
64.       end;
65.  
66.     begin
67.       Proc4(); { which Proc4 gets called - not the same one as above! }
68.     end;
69.  
70.   begin
71.     Proc4(); { which Proc4 gets called ? }
72.   end;
73.  
74. begin
75. end;
76.  
77.  
78.  
79. procedure TSome.Proc4;
80. begin
81. end;
82.  
83.  
84. begin
85. end.                              

if Proc1 and Proc2 are nested in TSome.Proc2 then the compiler is unhappy and emits an error BUT, if Proc1 and Proc2 are nested in Proc3, suddenly there is no more duplicate identifier, IOW, identifier "Proc1" is different than identifier "Proc1" and the same for "Proc2".

But, there can be a "Proc3" inside a "Proc3" inside another "Proc3" without any complaints about duplicate identifiers.   If that isn't enough, since an error is emitted when a "duplicate identifier" is found, that really puts in doubt which Proc4 is invoked by the various Proc3(s)

No wonder they say the road to hell is paved with good identifiers ... uh... I mean good intentions. 

It's much easier to figure things out when rules have no exceptions.   If the compiler is going to complain about "duplicate identifier"s then it should NOT allow any function/procedure/method to be named the same as another one in the entire hierarchy thus making it consistent.  IOW, all names unique in the entire scope.

Alternatively, if it wants to complain about "duplicate identifiers" then it should at least issue a warning for all duplicates it is willing to tolerate and an error for those it is not.  At least a semblance of consistency.

[Curt Carpenter]

It's a fairly esoteric problem in any event isn't it?  Although I agree that the introduction of an exception to scoping rules is unfortunate.

The question for computational linguists, I suppose, is whether any sufficiently rich language can ever be entirely free of such issues.   There will certainly always be trade-offs to be made in the design of such a language, and no provably optimal way to make them, given the diversity of interests and priorities that come into play.   

Meanwhile:  if protecting programmers from themselves was a leading principle -- would "C" ever have made it out of the laboratory?