pkg/api: add OptionalRepeatedString type

[marquiz]

No description provided.

[marquiz]

@klihub @chrishenzie @mikebrow

Pre-work for some of my upcoming work on managing the linux.intelRdt object of the runtime-spec. I decided to submit this one as a separate PR with the hopes of easier and more focused review.

I'm not sure if we need all the pointer's-pointer (or nil's-nil) stuff or would it be sufficient to return []string (instead of *[]string) from Get()

[klihub]

@klihub @chrishenzie @mikebrow

Pre-work for some of my upcoming work on managing the linux.intelRdt object of the runtime-spec. I decided to submit this one as a separate PR with the hopes of easier and more focused review.

I'm not sure if we need all the pointer's-pointer (or nil's-nil) stuff or would it be sufficient to return []string (instead of *[]string) from Get()

@marquiz. This is I think the only part I was wondering about. But you will probably get a much better understanding about what makes sense for Get() and what alternatives make sense for the constructor once you have written some more code exercising this. Then there are two options. Either start with the minimal set your code needs, or with what you guesstimate to be potentially necessary. But this already LGTM as such.

[chrishenzie]

+1 to @klihub 's comment -- would it be possible to add your intended use case as a separate commit in this PR so we can take a look how it's being used? I'd prefer to review that vs. merge now and have to make subsequent changes later

[mikebrow]

agree with your and the other comments.. without the use case, outside the test bucket itself, sort of hard to see whether some of the optional elements are a + or -

[marquiz]

Rebased, marked ready-for-review.
@klihub @mikebrow @chrishenzie

[klihub]

LGTM

[mikebrow]

attempt at adding clarity around the ensure clone comment I made.. #212 (comment)

[chrishenzie]

It looks like proto3 has a built-in optional keyword, but doesn't support optional repeated syntax.

Is the goal of this wrapper type to distinguish between a nil (unset) list and an empty list? If that distinction isn't critical for the intelRdt use case, could we simplify the API by using a standard repeated string field and treating an empty list as unset?

This probably is beyond the scope of this PR, but I'm just curious about this API choice that was made

[marquiz]

Is the goal of this wrapper type to distinguish between a nil (unset) list and an empty list?

Exactly. There are similar "optional" wrappers for other types. This follows suite

If that distinction isn't critical for the intelRdt use case, could we simplify the API by using a standard repeated string field and treating an empty list as unset?

For now, it's not critical. But I want to be able to make the difference whether the list was specified or not. Make sure that we're not caught off guard if the empty list get's a special meaning in the runtime-spec in the future.

[klihub]

@mikebrow We could try to kick this one and #215 (which is stacked on top of this) forward...

[mikebrow]

LGTM
nit some doc explanation on the involved funcs explaining that the wrapper is a shallow clone..

The slices.Clone function in Go creates a shallow copy of a slice, meaning it copies the elements but retains references to the same underlying data. This allows you to modify the cloned slice without affecting the original slice, as long as the elements themselves are not mutable types.

[klihub]

LGTM nit some doc explanation on the involved funcs explaining that the wrapper is a shallow clone..

The slices.Clone function in Go creates a shallow copy of a slice, meaning it copies the elements but retains references to the same underlying data. This allows you to modify the cloned slice without affecting the original slice, as long as the elements themselves are not mutable types.

@mikebrow Hmm..., okay. I read the code again, and if you mean slices.Clone() in the RepeatedString(v interface{}) 'constructor', then I think we always end up shallow-cloning a []string in the end, so there is no data left shared there. And the other one in Get() *[]string does the same with a more straightforward control flow.

[mikebrow]

LGTM nit some doc explanation on the involved funcs explaining that the wrapper is a shallow clone..

The slices.Clone function in Go creates a shallow copy of a slice, meaning it copies the elements but retains references to the same underlying data. This allows you to modify the cloned slice without affecting the original slice, as long as the elements themselves are not mutable types.

@mikebrow Hmm..., okay. I read the code again, and if you mean slices.Clone() in the RepeatedString(v interface{}) 'constructor', then I think we always end up shallow-cloning a []string in the end, so there is no data left shared there. And the other one in Get() *[]string does the same with a more straightforward control flow.

nod and strings are immutable in golang.. so even if the caller wanted to change one of those strings it would not be allowed.. feels odd.. but ok, guess I'm just missing C :-)