runtime(java): Improve the recognition of the "style" method declarations
- Request the new regexp engine (v7.3.970) for [:upper:] and
[:lower:].
- Recognise declarations of in-line annotated methods.
- Recognise declarations of _strictfp_ methods.
- Establish partial order for method modifiers as shown in
the MethodModifier production; namely, _public_ and
friends should be written the leftmost, possibly followed
by _abstract_ or _default_, or possibly followed by other
modifiers.
- Stop looking for parameterisable primitive types (void<?>,
int<Object>, etc., are malformed).
- Stop looking for arrays of _void_.
- Acknowledge the prevailing convention for method names to
begin with a small letter and for class/interface names to
begin with a capital letter; and, therefore, desist from
claiming declarations of enum constants and constructors
with javaFuncDef.
Rationale:
+ Constructor is distinct from method:
* its (overloaded) name is not arbitrary;
* its return type is implicit;
* its _throws_ clause depends on indirect vagaries of
instance (variable) initialisers;
* its invocation makes other constructors of its type
hierarchy invoked one by one, concluding with the
primordial constructor;
* its explicit invocation, via _this_ or _super_, can
only appear as the first statement in a constructor
(not anymore, see JEP 447); else, its _super_ call
cannot appear in constructors of _record_ or _enum_;
and neither invocation is allowed for the primordial
constructor;
* it is not a member of its class, like initialisers,
and is never inherited;
* it is never _abstract_ or _native_.
+ Constructor declarations tend to be few in number and
merit visual recognition from method declarations.
+ Enum constants define a fixed set of type instances
and more resemble class variable initialisers.
Note that the code duplicated for @javaFuncParams is written
keeping in mind for g:java_highlight_functions a pending 3rd
variant, which would require none of the :syn-cluster added
groups.
closes: #14620
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-04-24 21:04:25 +02:00
|
|
|
|
| +0&#ffffff0@74
|
|
|
|
|
|
@4|i+0#00e0003&|n|t|e|r|f|a|c|e| +0#0000000&|S|t|y|l|a|b|l|e|<|Α|>| @49
|
2024-06-16 09:42:55 +03:00
|
|
|
|
@4|{| @69
|
2024-09-15 19:53:50 +02:00
|
|
|
|
| +0#00e0e07&@7|d+0#00e0003&|e|f|a|u|l|t| +0#00e0e07&|v+0#00e0003&|o|i|d| +0#00e0e07&|a|s|c|i@1|$|0|_|(|)| +0#0000000&|{| |}| @39
|
|
|
|
|
|
| +0#00e0e07&@7|d+0#00e0003&|e|f|a|u|l|t| +0#00e0e07&|Α| |μ|ʭ@1|$|0|_|(|)| +0#0000000&|{| |r+0#af5f00255&|e|t|u|r|n| +0#0000000&|n+0#e000002&|u|l@1|;+0#0000000&| |}| @31
|
2024-06-16 09:42:55 +03:00
|
|
|
|
@4>}| @69
|
runtime(java): Improve the recognition of the "style" method declarations
- Request the new regexp engine (v7.3.970) for [:upper:] and
[:lower:].
- Recognise declarations of in-line annotated methods.
- Recognise declarations of _strictfp_ methods.
- Establish partial order for method modifiers as shown in
the MethodModifier production; namely, _public_ and
friends should be written the leftmost, possibly followed
by _abstract_ or _default_, or possibly followed by other
modifiers.
- Stop looking for parameterisable primitive types (void<?>,
int<Object>, etc., are malformed).
- Stop looking for arrays of _void_.
- Acknowledge the prevailing convention for method names to
begin with a small letter and for class/interface names to
begin with a capital letter; and, therefore, desist from
claiming declarations of enum constants and constructors
with javaFuncDef.
Rationale:
+ Constructor is distinct from method:
* its (overloaded) name is not arbitrary;
* its return type is implicit;
* its _throws_ clause depends on indirect vagaries of
instance (variable) initialisers;
* its invocation makes other constructors of its type
hierarchy invoked one by one, concluding with the
primordial constructor;
* its explicit invocation, via _this_ or _super_, can
only appear as the first statement in a constructor
(not anymore, see JEP 447); else, its _super_ call
cannot appear in constructors of _record_ or _enum_;
and neither invocation is allowed for the primordial
constructor;
* it is not a member of its class, like initialisers,
and is never inherited;
* it is never _abstract_ or _native_.
+ Constructor declarations tend to be few in number and
merit visual recognition from method declarations.
+ Enum constants define a fixed set of type instances
and more resemble class variable initialisers.
Note that the code duplicated for @javaFuncParams is written
keeping in mind for g:java_highlight_functions a pending 3rd
variant, which would require none of the :syn-cluster added
groups.
closes: #14620
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-04-24 21:04:25 +02:00
|
|
|
|
@75
|
2024-04-29 21:24:35 +03:00
|
|
|
|
@4|/+0#0000e05&@1| |F|I|E|L|D|S|.| +0#0000000&@60
|
2024-09-15 19:53:50 +02:00
|
|
|
|
@4|p+0#00e0003&|r|i|v|a|t|e| +0#0000000&|s+0#00e0003&|t|a|t|i|c| +0#0000000&|f+0#00e0003&|i|n|a|l| +0#0000000&|C|l|a|s@1|<|?|>| |C|L|A|S@1|_|L|O|C|K| |=| |c|l|a|s@1|L|o|c|k|(|)|;| @15
|
2024-04-29 21:24:35 +03:00
|
|
|
|
@75
|
2024-09-15 19:53:50 +02:00
|
|
|
|
@4|p+0#00e0003&|r|i|v|a|t|e| +0#0000000&|f+0#00e0003&|i|n|a|l| +0#0000000&|O|b|j|e|c|t| |i|n|s|t|a|n|c|e|L|o|c|k| |=| |n+0#af5f00255&|e|w| +0#0000000&|O|b|j|e|c|t|(|)|;| @21
|
runtime(java): Improve the recognition of the "style" method declarations
- Request the new regexp engine (v7.3.970) for [:upper:] and
[:lower:].
- Recognise declarations of in-line annotated methods.
- Recognise declarations of _strictfp_ methods.
- Establish partial order for method modifiers as shown in
the MethodModifier production; namely, _public_ and
friends should be written the leftmost, possibly followed
by _abstract_ or _default_, or possibly followed by other
modifiers.
- Stop looking for parameterisable primitive types (void<?>,
int<Object>, etc., are malformed).
- Stop looking for arrays of _void_.
- Acknowledge the prevailing convention for method names to
begin with a small letter and for class/interface names to
begin with a capital letter; and, therefore, desist from
claiming declarations of enum constants and constructors
with javaFuncDef.
Rationale:
+ Constructor is distinct from method:
* its (overloaded) name is not arbitrary;
* its return type is implicit;
* its _throws_ clause depends on indirect vagaries of
instance (variable) initialisers;
* its invocation makes other constructors of its type
hierarchy invoked one by one, concluding with the
primordial constructor;
* its explicit invocation, via _this_ or _super_, can
only appear as the first statement in a constructor
(not anymore, see JEP 447); else, its _super_ call
cannot appear in constructors of _record_ or _enum_;
and neither invocation is allowed for the primordial
constructor;
* it is not a member of its class, like initialisers,
and is never inherited;
* it is never _abstract_ or _native_.
+ Constructor declarations tend to be few in number and
merit visual recognition from method declarations.
+ Enum constants define a fixed set of type instances
and more resemble class variable initialisers.
Note that the code duplicated for @javaFuncParams is written
keeping in mind for g:java_highlight_functions a pending 3rd
variant, which would require none of the :syn-cluster added
groups.
closes: #14620
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-04-24 21:04:25 +02:00
|
|
|
|
@75
|
2024-04-29 21:24:35 +03:00
|
|
|
|
@4|/+0#0000e05&@1| |C|O|N|S|T|R|U|C|T|O|R|S|.| +0#0000000&@54
|
2024-06-16 09:42:55 +03:00
|
|
|
|
@4|@+0#e000e06&|T|ɐ|g@1|a|b|l|ɘ| +0#0000000&|@+0#e000e06&|T|ɐ|g@1|a|b|l|ɘ| +0#0000000&|p+0#00e0003&|r|o|t|e|c|t|e|d| +0#0000000&|S|t|y|l|e|M|e|t|h|o|d|s|T|e|s|t|s|(|)| |{| |}| @17
|
|
|
|
|
|
@4|<|T| |e+0#00e0003&|x|t|e|n|d|s| +0#0000000&|C|o|m|p|a|r|a|b|l|e|<|T|>@1| |S|t|y|l|e|M|e|t|h|o|d|s|T|e|s|t|s|(|T| |t|,| |V|o|i|d| |v|)| |{| |}| @10
|
|
|
|
|
|
@4|p+0#00e0003&|r|i|v|a|t|e| +0#0000000&|<|T| |e+0#00e0003&|x|t|e|n|d|s| +0#0000000&|C|o|m|p|a|r|a|b|l|e|<|T|>@1| |S|t|y|l|e|M|e|t|h|o|d|s|T|e|s|t|s|(|T| |t|)| |{| |}| @10
|
runtime(java): Improve the recognition of the "style" method declarations
- Request the new regexp engine (v7.3.970) for [:upper:] and
[:lower:].
- Recognise declarations of in-line annotated methods.
- Recognise declarations of _strictfp_ methods.
- Establish partial order for method modifiers as shown in
the MethodModifier production; namely, _public_ and
friends should be written the leftmost, possibly followed
by _abstract_ or _default_, or possibly followed by other
modifiers.
- Stop looking for parameterisable primitive types (void<?>,
int<Object>, etc., are malformed).
- Stop looking for arrays of _void_.
- Acknowledge the prevailing convention for method names to
begin with a small letter and for class/interface names to
begin with a capital letter; and, therefore, desist from
claiming declarations of enum constants and constructors
with javaFuncDef.
Rationale:
+ Constructor is distinct from method:
* its (overloaded) name is not arbitrary;
* its return type is implicit;
* its _throws_ clause depends on indirect vagaries of
instance (variable) initialisers;
* its invocation makes other constructors of its type
hierarchy invoked one by one, concluding with the
primordial constructor;
* its explicit invocation, via _this_ or _super_, can
only appear as the first statement in a constructor
(not anymore, see JEP 447); else, its _super_ call
cannot appear in constructors of _record_ or _enum_;
and neither invocation is allowed for the primordial
constructor;
* it is not a member of its class, like initialisers,
and is never inherited;
* it is never _abstract_ or _native_.
+ Constructor declarations tend to be few in number and
merit visual recognition from method declarations.
+ Enum constants define a fixed set of type instances
and more resemble class variable initialisers.
Note that the code duplicated for @javaFuncParams is written
keeping in mind for g:java_highlight_functions a pending 3rd
variant, which would require none of the :syn-cluster added
groups.
closes: #14620
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-04-24 21:04:25 +02:00
|
|
|
|
@75
|
2024-04-29 21:24:35 +03:00
|
|
|
|
@4|/+0#0000e05&@1| |M|E|T|H|O|D|S|.| +0#0000000&@59
|
2024-09-15 19:53:50 +02:00
|
|
|
|
| +0#00e0e07&@3|@+0#e000e06&|T|ɐ|g@1|a|b|l|ɘ| +0#00e0e07&|@+0#e000e06&|T|ɐ|g@1|a|b|l|ɘ| +0#00e0e07&|a+0#00e0003&|b|s|t|r|a|c|t| +0#00e0e07&|v+0#00e0003&|o|i|d| +0#00e0e07&|a|s|c|i@1|$|0|_|(|/+0#0000e05&@15| +0#0000000&@11
|
2024-04-29 21:24:35 +03:00
|
|
|
|
@57|3|7|,|2|-|5| @7|4|9|%|
|