-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add RFC for Fn::NumberComparison #90
base: main
Are you sure you want to change the base?
Conversation
Two questions:
|
Could the comparison function simply be expressed using words, e. g. |
If we're talking about NotMeetRetentionRequirement: !NumberComparison
- !Ref 'retentionInDays'
- LessThanOrEquals
- 365 I think that's probably worse. |
Why is it worse? |
it wouldn't help reduce CloudFormation's reputation for being verbose, for one thing |
I'd prefer verbosity over less functionality though. |
Would a NotMeetRetentionRequirement: !Maths "${retentionInDays} <= 365"
MeetsRetentionRequirement: !Maths [ "${x} <= 365", {x: !Ref retentionInDays} (to restrict this to boolean results |
|
||
* a hardcoded `Number` in the template | ||
* `Ref` to a Parameter of type `Number` | ||
* a `Number` outputted by the use of a Function |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of the Functions below (Fn::Sub
, Fn::Join
) only output strings, so with the current wording they shouldn't be supported
Here are a few fun yaml edge cases to think about (see also #31 (comment) to resolve at least some of these): Parameters
retentionInDays:
Description: Log retention in days
Type: Number
Parameters
retentionInDaysString:
Description: Log retention in days
Type: String
Conditions:
CastString: !NumberComparison
- !Ref 'retentionInDays'
- ==
- "365" # should this be cast to a number or fail?
CastParameter: !NumberComparison
- !Ref 'retentionInDaysString' # should this be cast to a number or fail?
- ==
- 365
Octal1: !NumberComparison
- !Ref 'retentionInDays'
- ==
- "0365" # If we cast, should this be 365 or 254 (= octal 365)
Octal2: !NumberComparison
- 0365
- ==
- "0365" # does the previous decision make this confusing? and do previous decisions influence the json behaviour? {"NotOctal": {"Fn::NumberComparison": [365, "==", "0365"]} I think for the current implementation it would make sense to never cast (so it's only the current 0365 == 0o365 == 254 yaml <1.2 problem). However, there are Resources that will return numbers in a String type, so that would block future expansion to use this with resources ( |
How about Opens the door to |
I'm not that worried about the actual name (although I think it's fun to imagine someone yelling "Maths!"). I would be careful with opening this up too much. Using the same function to edit data and to compare data seems like it would lead to problems later. I'd keep Eg: |
I can live with that. |
Given that it's been over a year since last movement on this issue, I figured it was worth a quick check-in ...
|
Language Enhancement Request For Comment
This is a request for comments about a new intrinsic function
Fn::NumberComparison
. See #80 foradditional details.
Licensing
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.