Skip to content
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

🧹 Use generic func to convert slices of a type to slices of interface #988

Closed
wants to merge 2 commits into from

Conversation

imilchev
Copy link
Member

doesn't change anything for the end user

Just replaced the core.StrSliceToInterface func with a generic function that works for slices of any type. We discussed this in #981 (comment)

Copy link
Member

@chris-rock chris-rock left a comment

Choose a reason for hiding this comment

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

Great harmonization @imilchev

resources/packs/core/core.utils.go Outdated Show resolved Hide resolved
@imilchev imilchev force-pushed the ivan/generic-slice-conversion branch from 50a7811 to de05673 Compare February 28, 2023 19:57
res := make([]interface{}, len(value))
for i := range value {
res[i] = value[i]
func SliceToInterfaceSlice[T any](ss []T) []interface{} {
Copy link
Member

Choose a reason for hiding this comment

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

Can we add a simple test case that checks:

  • slice of strings to interface
  • slide of strings with pointers and nil elements (this has worked before and nil elements where filtered, the new implementation behaves slightly different)

Copy link
Member Author

Choose a reason for hiding this comment

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

I added tests. Also made sure the behaviour remains the same although I don't think it's needed. The ptr function was used only in 1 place for azure sql resources. I don't think they return nil entries in slices. It could be that this check was added during development for some testing. Anyways, now the behaviour is identical

Copy link
Member

Choose a reason for hiding this comment

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

If it is just one place, lets test it without the old behavior and simplify the implementation

Copy link
Contributor

Choose a reason for hiding this comment

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

If we want this to be a generic function, I think we should keep the nil checks in place. The signature of that function allows you to pass in an array with nils in it, so we should assume that this can happen, otherwise we're making assumptions about the consumers of that function.

Right now it's used only in the azure stuff which probably will never give you back a nil pointer amongst the other stuff, but maybe 20 new API providers down the road some of those have weird APIs that also give you back nil entries in a list of pointers.

Instead, if you don't wanna keep that generic function then we can get rid of it and just do that conversion in the azure-related code directly

Signed-off-by: Ivan Milchev <[email protected]>
@chris-rock
Copy link
Member

@imilchev is that one still up to date. If we want to get this improvement in, we should rebase and add tests for the cases.

@preslavgerchev
Copy link
Contributor

We can probably close this?

@imilchev imilchev closed this Oct 10, 2023
@github-actions github-actions bot locked and limited conversation to collaborators Oct 10, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants