Review of unused property types
Some property types are unused or barely used:
-
MethodProperty -> can be removed altogether
-
TypeProperty -> I can see how having a property for types is useful, but the property descriptors have no access to the aux classpath for now, which means the conversion will fail more often than not. I think, we can drop it, maybe replace it with a QualifiedNameProperty specific to Java in the future (qualified names don't need the auxclasspath).
-
FileProperty -> used only in the following:
|
public static final FileProperty EXCEPTION_FILE_DESCRIPTOR = new FileProperty("exceptionfile", |
|
"File containing strings to skip (one string per line), only used if ignore list is not set", null, 5.0f); |
The use case is definitely erroneous and a StringMultiProperty should be used instead. It can be removed I think
-
FloatProperty -> never used, can be superseded by DoubleProperty
-
LongProperty is never used either, but I can't see a strong reason to drop it. It may be useful in the future.
New validation scheme
Validating the properties could be done in the property descriptor. With Java 8, we could add the following method addValidator(Predicate<T> pred) to the builders class, which would allow java rules to register a validator. If a value doesn't pass the tests, then the rule is reported as dysfunctional and not run. This would be very flexible, although it doesn't allow XPath rules to validate their value. We could add some common validators to the XPath syntax in a later stage.
With this is place, we can simply drop support for the custom package restrictions of PackagedProperty and the min/max of NumericProperty, which seemed to be getting in the way too often.
Since we're dropping these, we can also drop PropertyDescriptorField altogether. The schema only ever allowed the min and max attributes anyway.
Reunifying the multivalue and univalue properties
I think with a simple alteration of the ruleset schema we could drop the need for registering a delimiter, which means there need not be this big class hierarchy divide between multi- and single-value property descriptors (which would also reduce the number concrete property classes significantly). I'll describe that later.
TODO
I'm scheduling the deprecations for the next release. The actual API changes are good for 7.0.0.
Review of unused property types
Some property types are unused or barely used:
MethodProperty -> can be removed altogether
TypeProperty -> I can see how having a property for types is useful, but the property descriptors have no access to the aux classpath for now, which means the conversion will fail more often than not. I think, we can drop it, maybe replace it with a QualifiedNameProperty specific to Java in the future (qualified names don't need the auxclasspath).
FileProperty -> used only in the following:
pmd/pmd-java/src/main/java/net/sourceforge/pmd/lang/java/rule/errorprone/AvoidDuplicateLiteralsRule.java
Lines 52 to 53 in 84d1519
The use case is definitely erroneous and a StringMultiProperty should be used instead. It can be removed I think
FloatProperty -> never used, can be superseded by DoubleProperty
LongProperty is never used either, but I can't see a strong reason to drop it. It may be useful in the future.
New validation scheme
Validating the properties could be done in the property descriptor. With Java 8, we could add the following method
addValidator(Predicate<T> pred)to the builders class, which would allow java rules to register a validator. If a value doesn't pass the tests, then the rule is reported as dysfunctional and not run. This would be very flexible, although it doesn't allow XPath rules to validate their value. We could add some common validators to the XPath syntax in a later stage.With this is place, we can simply drop support for the custom package restrictions of PackagedProperty and the min/max of NumericProperty, which seemed to be getting in the way too often.
Since we're dropping these, we can also drop PropertyDescriptorField altogether. The schema only ever allowed the min and max attributes anyway.
Reunifying the multivalue and univalue properties
I think with a simple alteration of the ruleset schema we could drop the need for registering a delimiter, which means there need not be this big class hierarchy divide between multi- and single-value property descriptors (which would also reduce the number concrete property classes significantly). I'll describe that later.
TODO
I'm scheduling the deprecations for the next release. The actual API changes are good for 7.0.0.