Re: [fpc-devel] Language semantic suggesion regarding static methods
Op 2019-10-22 om 01:19 schreef J. Gareth Moreton: 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. We need less dialectal variety, not more. The ambiguity of having two forms in code bases is worse then any benefit the change could every have. People with established code habits and/or Delphi usage will stick with old, and new users might adopt the new if promoted enough. Result: chaos. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Language semantic suggesion regarding static methods
J. Gareth Moreton schrieb am Di., 22. Okt. 2019, 07:21: > 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 > following directives) > The parser will only know whether it's a directive or part of the next declaration once it parsed the semicolon. Currently it does not need to care. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Language semantic suggesion regarding static methods
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 following directives) 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 syntax: === code begin === class function Foo: Integer; static; function SomethingElse; vs. 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. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Language semantic suggesion regarding static methods
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 syntax: === code begin === class function Foo: Integer; static; function SomethingElse; vs. 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. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Language semantic suggesion regarding static methods
Hi everyone, This is a very low-level semantic issue, but I'm not particularly keen on how static methods are defined in classes. *class function *StaticMethod: Integer; *static;* What's wrong with it? Well, it's an issue of consistency that gets me, plus 'static' is only valid as part of a class method declaration, making it a very restrictive directive. I'm not sure how best to explain it, but there are three levels of 'connectivity' that a method can have with an object: *function *RegularMethod: Integer; // Self points to the calling object *class function *ClassMethod: Integer; // Self points to the calling class *class function *StaticMethod: Integer; *static;* // Self unavailable - effectively a regular subroutine tied to the class. To draw attention to the inconsistency, I doubt anyone would support syntax like this (or maybe they would... I don't know!): *function *ClassMethod: Integer; *class;* For one thing, it doesn't immediately jump out that the method is a class method, especially if there are a lot of parameters and it scrolls off the edge of the UI. For language consistency, surely a more logical syntax would be the following: *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. Granted I can live with it if it isn't going to be changed, but it's something that always bugged me! Gareth aka. Kit P.S. If I've missed something obvious as to why static methods are implemented using a directive, please educate me! -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
