Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 27.09.2012 19:33, Marco van de Voort wrote:
In our previous episode, Marcos Douglas said:
- Records... "R" (?)
- Constants... UPPER_CASE? cSomething?
At least we would have a good and unique style.
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.
{$scopedenums on/off} already works in FPC 2.6.0.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 2:43 PM, Michael Van Canneyt wrote: > > > On Thu, 27 Sep 2012, Marcos Douglas wrote: > >>> >>> I hope not :-) >> >> >> 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. > > > 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. Ok, I'm convinced. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, 27 Sep 2012, Marcos Douglas wrote: I hope not :-) 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. 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 2:26 PM, Michael Van Canneyt wrote: > > > On Thu, 27 Sep 2012, Marcos Douglas wrote: > 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. >> >> >> 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. > > > I do not think it is that black and white :) Maybe grey. Equilibrium. :) > 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 :-) 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
In our previous episode, Marcos Douglas said: > > - Records... "R" (?) > - Constants... UPPER_CASE? cSomething? > > At least we would have a good and unique style. 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, 27 Sep 2012, Marcos Douglas wrote: 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. 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. 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, 27 Sep 2012 13:52:53 -0300 Marcos Douglas wrote: > On Thu, Sep 27, 2012 at 12:34 PM, Graeme Geldenhuys > wrote: > > On 2012-09-27 16:08, michael.vancann...@wisa.be wrote: > >> > >> 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. :) > > 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 1:58 PM, Graeme Geldenhuys wrote: > On 2012-09-27 17:52, 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 Ok. But, even in Pascal, if you have the same variable written in many styles you can have confusion too. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 1:55 PM, Graeme Geldenhuys wrote: > On 2012-09-27 17:46, 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 1:48 PM, Michael Van Canneyt wrote: > > > On Thu, 27 Sep 2012, Marcos Douglas wrote: > >> On Thu, Sep 27, 2012 at 12:08 PM, wrote: >>> >>> >>> >>> On Thu, 27 Sep 2012, Marcos Douglas wrote: >>> > > 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. 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.). >>> >>> >>> >>> Exactly. >>> >>> The compiler helps you by forcing you to use a prefix in objfpc mode in >>> case >>> you forgot. >> >> >> The collisions exist because the compiler give us an error. If the >> compiler respect the scope, the collisions would not exist. > > > 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 2012-09-27 17:52, 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 2012-09-27 17:46, 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 12:34 PM, Graeme Geldenhuys wrote: > On 2012-09-27 16:08, michael.vancann...@wisa.be wrote: >> >> 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. :) 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, 27 Sep 2012, Marcos Douglas wrote: On Thu, Sep 27, 2012 at 12:08 PM, wrote: On Thu, 27 Sep 2012, Marcos Douglas wrote: 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. 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.). Exactly. The compiler helps you by forcing you to use a prefix in objfpc mode in case you forgot. The collisions exist because the compiler give us an error. If the compiler respect the scope, the collisions would not exist. 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 12:26 PM, Graeme Geldenhuys wrote: > On 2012-09-27 15:48, 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 12:08 PM, wrote: > > > On Thu, 27 Sep 2012, Marcos Douglas wrote: > >>> >>> 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. >> >> >> 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.). > > > Exactly. > > The compiler helps you by forcing you to use a prefix in objfpc mode in case > you forgot. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 2012-09-27 16:08, michael.vancann...@wisa.be wrote: > > 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 2012-09-27 15:48, 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 - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 2012-09-27 15:30, michael.vancann...@wisa.be wrote: > 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, 27 Sep 2012, Marcos Douglas wrote: 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. 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.). Exactly. The compiler helps you by forcing you to use a prefix in objfpc mode in case you forgot. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 11:53 AM, wrote: > > > On Thu, 27 Sep 2012, 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 11:33 AM, Jonas Maebe wrote:
>
> On 27 Sep 2012, at 16:18, Marcos Douglas wrote:
>
>> On Thu, Sep 27, 2012 at 11:01 AM, Jonas Maebe
>> wrote:
>>>
>>>
>>> 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.
>>
>>
>> Only Pascal uses that way?
>> How this works on Java, for example?
>
>
> 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.
>
>
>>> 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).
>>
>>
>> And this is normal, ie, use unit names like a property of classe?
>
>
> 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.
>
>
>>> Because {$mode objfpc} makes different trade-offs compared to {$mode
>>> delphi}. You can pick the one you like best.
>>
>>
>> I agree that should be different, but I think this broke the logical
>> syntax.
>
>
> 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.
>
>
>> 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.
>
>
> 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.
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, 27 Sep 2012, 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 11:30 AM, wrote: > > > On Thu, 27 Sep 2012, Marcos Douglas wrote: > >> On Thu, Sep 27, 2012 at 11:01 AM, Jonas Maebe >> wrote: >>> >>> >>> On 27 Sep 2012, at 15:51, Marcos Douglas wrote: >>> >>> 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? >>> >>> >>> 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. >> >> >> Only Pascal uses that way? > > > 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 27 Sep 2012, at 16:18, Marcos Douglas wrote:
On Thu, Sep 27, 2012 at 11:01 AM, Jonas Maebe > wrote:
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.
Only Pascal uses that way?
How this works on Java, for example?
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.
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).
And this is normal, ie, use unit names like a property of classe?
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.
Because {$mode objfpc} makes different trade-offs compared to {$mode
delphi}. You can pick the one you like best.
I agree that should be different, but I think this broke the logical
syntax.
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.
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.
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, 27 Sep 2012, Marcos Douglas wrote: On Thu, Sep 27, 2012 at 11:01 AM, Jonas Maebe wrote: On 27 Sep 2012, at 15:51, Marcos Douglas wrote: 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? 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. Only Pascal uses that way? 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On Thu, Sep 27, 2012 at 11:01 AM, Jonas Maebe wrote:
>
> On 27 Sep 2012, at 15:51, Marcos Douglas wrote:
>
> 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?
>
>
> 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.
Only Pascal uses that way?
How this works on Java, for example?
> 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).
And this is normal, ie, use unit names like a property of classe?
> 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.
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Local variable names and colision with attributes/properties names
On 27 Sep 2012, at 15:51, Marcos Douglas wrote:
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?
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___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Local variable names and colision with attributes/properties names
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
