[fpc-devel] Language semantic suggesion regarding static methods
J. Gareth Moreton
gareth at moreton-family.com
Tue Oct 22 07:21:02 CEST 2019
Fair enough. Thanks Sven. It just seemed to be a bit of an anomaly in
my eyes. (The ambiguity shouldn't be an issue because of the semicolon
Just something I thought I'd bring up.
Gareth aka. Kit
On 22/10/2019 06:17, Sven Barth via fpc-devel wrote:
> Am 22.10.2019 um 01:19 schrieb J. Gareth Moreton:
>> This is a very low-level semantic issue, but I'm not particularly
>> keen on how static methods are defined in classes.
> Not being "keen" on an existing, established syntax is not reason
> enough to change it.
> Please also note (to probably annoy you further) that static methods
> inside records use exactly the same syntax. ;)
>> *static function *StaticMethod: Integer;
>> For backward compatibility, I would suggest keeping the 'static'
>> directive for class methods so existing code doesn't break, but maybe
>> mark it as deprecated.
> This would introduce ambiguity especially with keeping the original
> === code begin ===
> class function Foo: Integer; static;
> function SomethingElse;
> class function Foo: Integer;
> static function SomethingElse;
> === code end ===
> The static directive is - like all other directives - parsed by
> parse_proc_directives and it would consume the "static" token in both
> cases. Then it would need to check for the existance of a "function"
> or "procedure" token and pass that up it's call change. There are
> places in the parser where this is indeed done, but adjusting the
> parser that much for *no* gain is not something we like to do.
>> P.S. If I've missed something obvious as to why static methods are
>> implemented using a directive, please educate me!
> Simple: Delphi compatibility.
> fpc-devel maillist - fpc-devel at lists.freepascal.org
This email has been checked for viruses by Avast antivirus software.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-devel