You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you very much for the thoroughly and detailed written RFC to add Go support to the CDK! I really enjoyed the read. I had a couple of questions along the lines which I dumped below. It would be great to get your thoughts/feedback on them to clarify them in the RFC.
Optionals
Particularly, this is an issue for methods with optional arguments and interfaces/structs/classes with optional fields.
The accepted solution for this in Go, is to use a pointer to the corresponding type, as pointers can be nil.
Another commonly used way of expressing "optional" parameters in Go is using the functional options pattern, e.g. as used in etcd, grpc, etc. I was immediately sold on it, not sure if this pattern is compatible with jsii though.
Immutable Structs
Depending on the struct field definitions, IMHO immutability might not be guaranteed when using pointers in field values, even though using the proposed non-pointer sharing in functions/methods.
if structs are always passed by-value, mutations of a struct performed by a function that received it will never
be visible to the caller, effectively maintaining the immutability from the point of view of the caller
Pass-by-value description
I think it's a typo here as "pass by reference" is likely what the author meant to say here. But please also remember: : in Go all function parameters are passed by value, incl. pointer types. I think it's better to avoid the pass-by-value/reference distinction in the context of Go.
// in package ecs, the struct is passed by value:funcTakesBaseServiceProps(props&BaseServiceProps) { /* ... */ }
Hope this makes sense.
The text was updated successfully, but these errors were encountered:
hey @embano1, sorry for the delay we aren't in the habit of monitoring this repo for issues re: questions on existing RFCs, though it makes sense that we should be. Could you write me an example of consuming a CDK construct using functional option params instead of pointer everywhere? I'm having trouble imagining it based on the slideshow you linked.
On Immutability in structs I may also need to see an example of when this could be abused. I assume this is when a struct has a field with a pointer type and technically the user can change the value the pointer is pointing too without the pointer itself changing hence upholding the immutability in Go land.
On pass by value/reference, JSII itself has a distinction between by value and by reference data coming over the wire so I assume that is what we are referring to but if you think there are some typos throw up a PR and I can take a look.
TY for the feedback, we are always looking for experiences from Go experts so reach out to us on https://cdk.dev/ if you have any more stuff you want to discuss (just so we don't miss it here).
@embano1 I'm gonna close this for now since we don't use this repo for ongoing issues really but comment with responses if you have any still and I'll see it. If you want to create issues on the aws/jsii repo with suggestions feel free as well.
Description
Thank you very much for the thoroughly and detailed written RFC to add Go support to the CDK! I really enjoyed the read. I had a couple of questions along the lines which I dumped below. It would be great to get your thoughts/feedback on them to clarify them in the RFC.
Optionals
Another commonly used way of expressing "optional" parameters in Go is using the functional options pattern, e.g. as used in etcd, grpc, etc. I was immediately sold on it, not sure if this pattern is compatible with
jsii
though.Immutable Structs
Depending on the struct field definitions, IMHO immutability might not be guaranteed when using pointers in field values, even though using the proposed non-pointer sharing in functions/methods.
Pass-by-value description
I think it's a typo here as "pass by reference" is likely what the author meant to say here. But please also remember: : in Go all function parameters are passed by value, incl. pointer types. I think it's better to avoid the pass-by-value/reference distinction in the context of Go.
Hope this makes sense.
The text was updated successfully, but these errors were encountered: