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

[Micha Nelissen]

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'.

> 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.

> 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.

> 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.'.

Micha