Recent

Author Topic: duplicate identifier  (Read 1057 times)

ASerge

  • Hero Member
  • *****
  • Posts: 2223
Re: duplicate identifier
« Reply #15 on: November 27, 2022, 11:15:42 pm »
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

  • Hero Member
  • *****
  • Posts: 3946
Re: duplicate identifier
« Reply #16 on: November 28, 2022, 12:11:42 am »
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.


(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Curt Carpenter

  • Sr. Member
  • ****
  • Posts: 396
Re: duplicate identifier
« Reply #17 on: November 28, 2022, 12:26:47 am »
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?   

 

TinyPortal © 2005-2018