Hi,

What is the advantages to the compiler return the error bellow?
ERROR: unit1.pas(31,3) Error: Duplicate identifier "FooVar"

Why the compiler do not respect the scope, ie, the local variable should have the preference, I'm not right?

Not? Why I can use a unit name as a property in my class, so? (see bellow the "StdCtrls" property name).

If I use {mode delphi} I can compile... I know. Why not in {mode objfpc} too?

See an example code:

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { private declarations }
  public
    FooVar: string;
    StdCtrls: string;
  end;
var
  Form1: TForm1;
implementation
{$R *.lfm}
procedure TForm1.Button1Click(Sender: TObject);
var
  FooVar: string;
begin
  FooVar := 'foo';
  StdCtrls := 'Is that right?';
end;
end.

Best regards,
Marcos Douglas

Yes, but the human brain is very good at confusing such things, and it's very easy to accidentally assign something to a local variable instead of to a field.

Not? Why I can use a unit name as a property in my class, so? (see bellow the "StdCtrls" property name).

Because the compiler only checks for identifiers defined in the current unit. You also cannot assign anything to a "unit", nor "read" from it, so there is generally less ambiguity (it still can exist in case the field is a record/class/object and contains fields that have the same name as global variables declared in the unit, but that's not exactly common).

If I use {mode delphi} I can compile... I know. Why not in {mode objfpc} too?

Because {$mode objfpc} makes different trade-offs compared to {$mode delphi}. You can pick the one you like best.

Jonas

Only Pascal uses that way?
How this works on Java, for example?

And this is normal, ie, use unit names like a property of classe?

I agree that should be different, but I think this broke the logical syntax.

Another: You always use a common name to represent a local variable, like Task. If tomorrow you implement a property called Task, you need to replace all Task local names. You can use the IDE to do this, ofcourse, but you would replace others identifiers inside of strings, for example.

Marcos Douglas

No, the brain works that way.

The FPC team decided to protect you from accidental mistakes by forbidding this special case in $mode objfpc.

For me, it has become second nature never ever to have a variable with the same name as a property, even in Delphi.

Michael.

Java doesn't put any restrictions on things like that. And it's not "Pascal" that works this way, it's FPC-specific. At least Ada most likely has something similar though.

I don't know how common that is, but as mentioned: it is much less likely to result in errors than having local variables with the same name as properties/fields/methods.

It's a trade-off: it has both good and bad aspects. We believe the good ones outweigh the bad ones. It was introduced after a bug was discovered in the compiler itself that was caused by such a problem.

Yes, it's always possible. In practice, I haven't seen this happen a single time in the 10+ years that the compiler has had this feature. That doesn't mean that it's impossible, but it's another factor in the "good to have" versus "causes more harm than good" equation.

Jonas

How do you know if you are using a function or method? For example, I can code a StrToInt method in my class. You can extend it. The "StrToInt method" is now in other unit and you "can't see it". Now you code:
blablabla

  i := StrToInt(x);

blablabla

Which StrToInt are you using? How our brains could help here? BUT, if you use:
Self.StrToInt(x)
... you know what is happening.

But this is a programmer's choice, ie, using or not the Self. The problem, IMHO, is that I can't choose when we talk about local variables.

Marcos Douglas

Marcos Douglas wrote

But this is a programmer's choice, ie, using or not the Self. The problem, IMHO, is that I can't choose when we talk about local variables.

You can: Use delphi mode.

Michael.

Well, happened on the own compiler. ;-)
IMHO, these collisions happen a lot and because of this many programmers use prefixes in local variables, see:
lNet, fpGUI, tiOPF2, Indy, and even Delphi (DateUtils unit eg.).

Marcos Douglas

As I said, I know this is works in delphi mode.
But I ask: In delphi mode this feature is Ok, but not in objfpc mode?

Why not exists a compiler directive and leave the programmer make your own choice? ;-)

Marcos Douglas

Exactly.

The compiler helps you by forcing you to use a prefix in objfpc mode in case you forgot.

Michael.

For me, it has become second nature never ever to have a variable with the same name as a property, even in Delphi.

+1

G.

Marcos Douglas wrote

problem, IMHO, is that I can't choose when we talk about local variables.

Just like there is a coding style (not language rule) that classes start with the "T" prefix, and class field variable start with a "F" prefix, I applied that same coding style to parameters and local variables.

"L" prefix for local variable - though I prefer the lowercase 'l' for this for some add reason. The exception being counter variables like x, y, i, j etc.

"A" prefix for parameter variables.

Using this simple coding style makes things even more logical and less confusing, even though I use mode objfpc for 90% of my code.

Regards,
- Graeme -

The compiler helps you by forcing you to use a prefix in objfpc mode in case you forgot.

The change in FPC mode objfpc was definitely a good thing. I had code where a class had an Index property, and other methods of that class had an Index parameter name. Even though it was my own code, I had to triple check the method's implementation to find the real meaning when I used the Index identifier somewhere in that method.

Now with the new language rule, I don't have such issues any more. Index will be the property name, AIndex will be the parameter, lIndex will be a local variable. Much simpler for my brain to process. :)

Graeme.

The collisions exist because the compiler give us an error. If the compiler respect the scope, the collisions would not exist. However we can use "poor names" -- very difficult to happen a collision -- to represent a variable like A, J, D... but I do not think this is a good practice and you?

Marcos Douglas

Marcos Douglas

Because "l" is more beautiful than "L" because is less "verbose". ;-)

"A" prefix for parameter variables. Using this simple coding style makes things even more logical and less confusing, even though I use mode objfpc for 90% of my code.

I do the same:
https://github.com/mdbs99/Greyhound/blob/master/src/gh_db.pas

But I do not like inconsistencies: a) I can use unit names in properties 2) I can use the same name in methods and procedures... etc... but I can not use local variables with the same name as a property(!)

Almost everything is Ok and beautiful -- well still lacks "namespace" feature that you also agree with me -- but not this design using local variables.

This "feature" have the origin in a bug in compiler. Well... "If you have a fever, it is best to break the thermometer?"

Marcos Douglas

Marcos Douglas

I know there is no collision in the strict sense of the word. There is just the very real possibility of making human mistakes.

However we can use "poor names" -- very difficult to happen a collision -- to represent a variable like A, J, D... but I do not think this is a good practice and you?

I do think this is good practice.
I will seldom use variable names of more than 2 characters.

Michael.

I never said this is wrong. I just said that could be a compiler directive or something like that.

I agree that is much simpler... but why nobody, in another language, do the same? Does not worth it? I do not know.

Marcos Douglas

Marcos Douglas wrote

This "feature" have the origin in a bug in compiler.

Yeah, but it takes a human to debug such issues. The compiler might have no problem understanding complex scopes, but the same could not always be said for programmers.

My code was affected by this change too, but all-in-all, I think it was a good move. Promote the idea of "easier to read and understand" code - the original goals of Pascal.

Graeme.

Marcos Douglas wrote

I agree that is much simpler... but why nobody, in another language, do the same? Does not worth it? I do not know.

Well, other languages have there own quirks like case sensitive identifiers. Thank God, Object Pascal doesn't have that.

Just imagine.

  var
    MyName: string;
    MYNAME: string;
    MYName: string;
    myName: string;
    myname: string;
  begin
    ...
  end;

:-D

Graeme.

So, just a letter "J" tell us everything we need about the variable? IMHO this contradicts the spirit of Pascal, a beautiful and readable language, but I guess I will lost this discussion.

Marcos Douglas

I agree. But because the same feature I see programmers using poor names in local variables.
Ok, just say: use a prefix. But each one programs using the own style! See FPC code, Lazarus code, etc. Even in the same project, you see many styles.

Maybe would be better to force everyone (no sarcarm) to use:
- Classes should have the prefix "T";
- Arguments should have the prefix "A";
- Local variables should have the prefix "L" or "l"
- Pointer..."P";
- Interfaces... "I";
- Records... "R" (?)
- Constants... UPPER_CASE? cSomething?

At least we would have a good and unique style.

Marcos Douglas

Ok.
But, even in Pascal, if you have the same variable written in many styles you can have confusion too.

Marcos Douglas

Just an example:
In Java the name clash is allowed. In the courses I attended many students confuse their variables so much that they think they must always prepend "this" to all member variables. So instead of prepending the parameters, they prepend the members.
This is one of the most confused "features" of Java.

I'm glad objfpc is less ambiguous than mode Delphi.

Mattias

I do not think it is that black and white :)

I agree that parameter names and global constants should have clear names, (so code completion is actually useful) but for local variables, I do not think this is necessary.

Do you think this

   For MyVeryClearName := StartValue to EndValue do
     MyVerLargeArray[MyVeryClearName]:=MyVeryClearName;

Is better than this:

   For I:=S to E do
     A[i]:=I;

I hope not :-)

And it's not about the size of variable names.
It's just about avoiding duplicate names which can lead to confusion.

Michael.

In our previous episode, Marcos Douglas said:

IMHO, that's taking it too far. Usually there is only made a difference between scopes (e.g. field and parameter, or global symbol and field), that could cause confusion. Within the same scope, duplicate identifiers are already excluded.

The Delphi notation is not entirely consistent though, the interface "I" prefix convention e.g. is therefore not that logical, and probably inherited.

Enums are also commonly prefixed, but I wouldn't mind an option to turn enums into a different scope (so that you can only use them qualified). IIRC a recent Delphi adds such switch, but I'm already used to it from my M2 days.

Maybe grey. Equilibrium. :)

Of course the second is (a little) better.

But, If you permits:
for i := StardValue to EndValue do
  MyArray[i] := i;

Now is more readable. More verbose than the first but less verbose than second. ;)

And it's not about the size of variable names. It's just about avoiding duplicate names which can lead to confusion.

You right but:
- prefix increases the size :P
- variables abbreviated are more easy to programmers do not use the same names to, objects, primitives variables, etc.

Marcos Douglas

Once we had the following code in Delphi:

Procedure TMyComponent.DoSomething;
Var
   B : String;
begin
   // complex code to calculate B. Prop is a property of the component.
   Prop:=B
end;

Someone, while fixing a bug, introduced then

Procedure TMyComponent.DoSomething;
Var
   B : String;
   Prop : String;
begin
   // complex code
   Prop:=B
end;

And all of a sudden, our program no longer worked. It took us a long time to find the error, namely an newly introduced local variable.

This kind of error is simply impossible in objfpc mode.

Michael.

Ok, I'm convinced.

Marcos Douglas

{$scopedenums on/off} already works in FPC 2.6.0.

Regards,
Sven