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

Questions on the Go Bindings RFC #313

Closed
embano1 opened this issue Apr 9, 2021 · 2 comments
Closed

Questions on the Go Bindings RFC #313

embano1 opened this issue Apr 9, 2021 · 2 comments

Comments

@embano1
Copy link
Member

embano1 commented Apr 9, 2021

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

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:
func TakesBaseServiceProps(props &BaseServiceProps) { /* ... */ }

Hope this makes sense.

@MrArnoldPalmer
Copy link
Contributor

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).

@MrArnoldPalmer
Copy link
Contributor

@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.

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

No branches or pull requests

3 participants