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 _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
