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

[Vinzent Hoefler]

On Tuesday 03 October 2006 11:15, Micha Nelissen wrote:
> On Tue, Oct 03, 2006 at 07:36:11AM +0000, Vinzent Hoefler wrote:
> > On Monday 02 October 2006 17:16, Micha Nelissen wrote:
> > > Ok, so enforcing different names is good then, that makes code
> > > more context insensitive, since identifiers won't suddenly
> > > "resolve" to parameters with the same name.
> >
> > No, it's more like the other way around. You get sudden name
> > clashes which you didn't have before, because in the other class
> > the field which clashes with your wisely chosen parameter name
> > didn't exist.
>
> We should be talking about semantics, not about 'compabilility
> whatever the resulting meaning may be'.

Yes, but the semantics is clear due to scoping rules. It may not be 
obvious, though. ;)

> > There's a reason, I always write "self.Identifier" and I also
> > refuse to revert back to the so called Hungarian notation (like
> > AParameter). Even if there is *no* parameter and/or field with that
> > name it's always clear which part is meant.
>
> This is not Hungarian notation. Hungarian is to prefix variable names
> with the (abbreviated) type.

Oh, come on. It's still a meaningless prefix not checked by anyone, at 
last the compiler. Especially when software gets changed usually the 
prefixes remain for whatever "historical reason" and the meaning 
changes (anyone remember LPSZSomething? Long Pointers are gone since 
ages, but the type names remained for "compatibility"), so those 
prefixes are much more dangerous than they appear at first sight, if 
you trust them. And if you don't trust them, that means you check it 
for yourself and then you can get rid of them, because the serve no 
purpose other than making variable names totally unreadable.

> > It would be more wise to warn about name clashes between units,
> > because for example NewStr is defined in objects.pas and in
> > classes.pas (IIRC), but depending on which one and how it is used
> > your program may crash.
>
> Agree, it's separate, but a good point.

Well, I don't consider it *that* separate. There's a "scoping" rule 
defined by the language and as such there are no ambiguities (at 
compiler level), yet it's not obvious to the developer. Change the 
order in which units are included and the semantics may change. Of 
course, the semantic change would still be defined by the language.

I remember trying to compile some TP7 code and I couldn't figure out 
what went wrong until I noticed there was one unit included that 
defined a variable called "Break".

Finally finding why 

|if condition then
|   break;

didn't compile anymore although it did a couple of days before taught me 
to always use the full name prefixed by the unit's name.

> > As long as such problems exist in the language definition itself,
> > this whole discussion about "cleaner code" and if such syntactic
> > checks are needed is f*cking pointless, because the language
> > already forces you to use fully qualified names anyway if you want
> > to avoid such problems. So you can as well use "self" to distiguish
> > between parameters and fields even if they have the same name.
>
> In theory, yes, but in practice nobody prefixes every field usage of
> self with 'Self.'.

Not even counting my"self" (and not counting Ada programmers, where 
similar things are much more common, because there the compiler stops 
at any *possible* ambiguity), I know at *least* two nobodies then.

And hell, I lost track how often have I seen "this. ..." in highly 
modern Java code. ;) So it seems much more common than you may think.


Vinzent.