-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > What could be a rood reason to escape a keyword? Why do you > as programmer insist on the use of a keyword? Why do you > insist that your property is called 'unit'? It's just > obfuscating the code. With this you can mangle your code completely...
Delphi (and Chrome) introduced this escaping mechanism because they had to survive in an environment where they needed to consume and extend types which have been defined in another language with a different set of reserved keywords. It is NOT intended for you to go wild and start naming everything with funny names. The example given was purely my test project to see if it works. Not intended as an example of what you should do. With FPC supporting different modes and keywords being dependant on mode you are in exactly the same boat as Delphi and Chrome. You might need to access symbols that for you (under the current mode) are a keyword but under the mode where they were declared are just an identifier. As Delphi _does_ support this mechanism, if you are interested in keeping compatibility to Delphi you'll have to at least allow this mechanism in $mode delphi. Just to say it again. This is not a mechanism that should be used for anything but compatibility. If you want to enforce the limitation of the use to compatibility only it's possible to introduce additional checks in the parsing stage (as opposed to the tokenizer where this is currently implemented) that prohibits the use of this mechanism in any cases not related to using or extending an already existing type (meaning that e.g. for declaring methods it is only acceptable if the method is used to implement an interface or to override a virtual method that already has this name). That way you could prevent people from abusing this functionality. > And about the 'method' thing... We could also replace the 'property' > keyword by 'something'. Hey, we can also replace method by > 'something'! > Woudn't that be nice. So you get: > > type > TMyObject = class > Fs : String; > something Foo; > something Bar: Integer; > class something ClassFoo; > class something ClassBar: Integer; > something s : read Fs write Fs; > end; > > Hmm... maye it's better to get rid off 'something' completely, then... > > In short: why do ou want to get rid of the difference between > 'procedure' and 'function'? > > Or do I miss something completely? Yes, replacing property with the same keyword creates ambiguities that would require multi token lookahead to resolve. Combining function and procedure into the same keyword does not introduce any ambiguity. You might have noticed that both are represented by the same tprocdef. Their code is generated in the same way and they are called in the same way. From a grammar standpoint "function" and "procedure" are really just noise words. The grammar inside these 2 productions is identical except for one requiring and the other prohibiting a specific sub production. The distinction between procedure and function is an artificial one, take the production for function, make the resulttype optional and you have merged the 2 without creating any ambiguity. Property and methods on the other hand have totally different productions, are represented by different defs, are used in different ways. Using the same keyword for that would be lunacy. ;) I also want to point out that I'm in no way proposing of adding this to any of the existing modes. I've added it to a new mode Chrome. As for "why do you want to get rid of...", for the same reason you do anything that you do in $mode delphi. Because THEY already did it. (Just in case anyone doesn't know what Chrome is and thinks I'm inventing a new language myself here: http://www.chromesville.com/ ). Cheers, Thorsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) iD8DBQFFtc72tgfmGfGfuPARAtIdAKCGGx7Ag0VuqmdN+49vf5xcmpqfJgCeKoCh MGZG70cVaBaqDRfM8tTyQnw= =Dwvy -----END PGP SIGNATURE----- _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
