Skip to content

Conversation

@BrandonChanSkybox
Copy link

Adds Metadata support for Property and Argument Minimum and Maximum bounds info

Copy link
Contributor

@SBLMikeDemone SBLMikeDemone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just a few unnecessary changes and some mild confusion around the new argument comments

}
}
},{
"has_max": false,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we drop the has_min/has_max flags and just rely on the min/max being present?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. By default, our bounds are set to a Type's numeric limits, (the absolute minimum and maximum values). Because of that, min/max will almost always be present. The has_min and has_max flag distinguish whether the min_value and max_value provided are different from the numeric limits of the Type.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

                {
                    ...
                    "has_max": true,
                    "has_min": false,
                    "max_value": 255,
                    "min_value": -2147483648, // Can we remove automatically added limits like this?
                    "type": {
                        ...
                        "valid_range": {
                            "max": 2147483647,
                            "min": -2147483648
                        }
                    }
                }

I wonder if we should change that. Types already have a "valid range" right? Is there a reason that we always stamp down "min_value" and "max_value" even if a binding doesn't specifically add limits?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah we chatted about this, the valid range is wrong, it's hardcoded to int min/max. We were gonna do a follow up that fixes that and then gets rid of has_max/has_min.

Alternatively, I find it weird that "type" even has a "valid_range". The generator could just have a map of type -> valid range and that'd get rid of quite a lot of metadata.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made follow up here: Task 1527387: [Infra] [Scripting] Calculate has_min and has_max value in metadata

@BrandonChanSkybox We'll need to validate this change works in MC and then merge it into MC, and it may make more sense to just do all this in 1 PR after you're back in vacation. It'll result in less metadata changes over time and less updates to the generator. What do you think?

Comment on lines +392 to +397
min_added: Optional(Boolean),
min_changed: Optional(Boolean),
min_removed: Optional(Boolean),
max_added: Optional(Boolean),
max_changed: Optional(Boolean),
max_removed: Optional(Boolean),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zachcampbellskyboxlabs is there any way to specify these types should only show up in the changelog?

Copy link
Contributor

@SBLMikeDemone SBLMikeDemone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense to me, just 2 small nits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants