Discussed in #904
Originally posted by BernieWhite January 7, 2022
Across expressions (used in YAML and JSON resources) and assertion methods (used in PowerShell resources) there are different names used to equivalent functionality. While terminology differs between programming/ scripting languages we want to make it even easier to understand and author rules.
We should look to realign naming to be ideally the same for expressions and assertion methods.
This discussion proposes the following naming changes.
| Expression |
Assertion method |
Proposed change |
| Contains |
Contains |
No change |
| Count |
Count |
No change |
| Equals |
n/a |
See note (1) |
| EndsWith |
EndsWith |
No change |
| Exists |
HasField |
Rename assertion method to Exists. |
| Greater |
Greater |
No change |
| GreaterOrEquals |
GreaterOrEqual |
Rename expression to GreaterOrEqual. |
| HasDefault |
HasDefaultValue |
Rename assertion method to HasDefault. |
| HasSchema |
HasJsonSchema |
Rename assertion method to HasSchema. |
| HasValue |
n/a |
See note (1). |
| In |
In |
No change |
| IsLower |
IsLower |
No change |
| IsString |
IsString |
No change |
| IsUpper |
IsUpper |
No change |
| Less |
Less |
No change |
| LessOrEquals |
LessOrEqual |
Rename expression to LessOrEqual. |
| Match |
Match |
No change |
| NotEquals |
n/a |
No change |
| NotIn |
NotIn |
No change |
| NotMatch |
NotMatch |
No change |
| SetOf |
SetOf |
No change |
| StartsWith |
StartsWith |
No change |
| Subset |
Subset |
No change |
| Version |
Version |
No change |
| n/a |
FileHeader |
No change |
| n/a |
FilePath |
No change |
| n/a |
HasFields |
No change |
| n/a |
HasFieldValue |
See note (1) |
| IsArray |
IsArray |
See note (2) |
| IsBoolean |
IsBoolean |
See note (2) |
| IsDateTime |
IsDateTime |
See note (2) |
| IsInteger |
IsInteger |
See note (2) |
| IsNumeric |
IsNumeric |
See note (2) |
| n/a |
JsonSchema |
No change |
| n/a |
NotHasField |
No change |
| n/a |
NotNull |
No change |
| NotWithinPath |
NotWithinPath |
See note (3) |
| n/a |
Null |
No change |
| n/a |
NullOrEmpty |
No change |
| n/a |
TypeOf |
No change |
| WithinPath |
WithinPath |
See note (3) |
https://microsoft.github.io/PSRule/v2/concepts/PSRule/en-US/about_PSRule_Expressions/#hasvalue
https://microsoft.github.io/PSRule/v2/concepts/PSRule/en-US/about_PSRule_Expressions/#equals
https://microsoft.github.io/PSRule/v2/concepts/PSRule/en-US/about_PSRule_Assert/#hasfieldvalue
Discussed in #904
Originally posted by BernieWhite January 7, 2022
Across expressions (used in YAML and JSON resources) and assertion methods (used in PowerShell resources) there are different names used to equivalent functionality. While terminology differs between programming/ scripting languages we want to make it even easier to understand and author rules.
We should look to realign naming to be ideally the same for expressions and assertion methods.
This discussion proposes the following naming changes.
Exists.GreaterOrEqual.HasDefault.HasSchema.LessOrEqual.Equals,HasValueand expression andHasFieldValueare approximate. Also these are not necessarily intuitive.Empty,NotEmpty, andEqualacross expressions and assertion methods. Then deprecateEquals,HasValueandHasFieldValue.https://microsoft.github.io/PSRule/v2/concepts/PSRule/en-US/about_PSRule_Expressions/#hasvalue
https://microsoft.github.io/PSRule/v2/concepts/PSRule/en-US/about_PSRule_Expressions/#equals
https://microsoft.github.io/PSRule/v2/concepts/PSRule/en-US/about_PSRule_Assert/#hasfieldvalue