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

Libs(Go): add convenience constructor for static nullable strings #1497

Merged
merged 1 commit into from
Oct 30, 2024

Conversation

svix-onelson
Copy link
Contributor

@svix-onelson svix-onelson commented Oct 29, 2024

Fixes #1198

While this isn't quite the type of change that was requested in #1198, I'm hopeful it'll reduce a bit of the friction.

A new constructor is now available as svix.StaticNullableString() which gives an openapi.NullableString.

Note that the return type (not a pointer) is inconsistent with the rest of the functions that act as primative constructors, and in fact goes against the convention of constructors returning pointers to the value they initialize.

The issue was raised, however, that all the places in the lib where a NullableString is needed, we'd have to dereference it anyway.
Since this alt constructor is all about convenience, we may as well break convention. In for a penny, in for a pound...

The net effect is instead of:

appIn := svix.ApplicationIn{
	...
	Uid: *svix.NullableString(svix.String("myuid"))
}

folks will now be able to write:

appIn := svix.ApplicationIn{
	...
	Uid: svix.StaticNullableString("myuid")
}

Fixes <#1198>

While this isn't quite the type of change that was requested in #1198,
I'm hopeful it'll reduce a bit of the friction.

A new constructor is now available as `svix.StaticNullableString()`
which gives an `openapi.NullableString`.

Note that the return type (not a pointer) is inconsistent with the rest
of the functions that act as primative constructors, and in fact goes
against the convention of constructors returning pointers to the value
they initialize.
The issue was raised, however, that all the places in the lib where a
`NullableString` is needed, we'd have to dereference it anyway.
Since this alt constructor is all about convenience, we may as well
break convention. _In for a penny, in for a pound..._

The net effect is instead of:

```go
appIn := svix.ApplicationIn{
	...
	Uid: *svix.NullableString(svix.String("myuid"))
}
```

folks will now be able to write:

```go
appIn := svix.ApplicationIn{
	...
	Uid: svix.StaticNullableString("myuid")
}
```
@svix-onelson svix-onelson marked this pull request as ready for review October 29, 2024 23:42
@svix-onelson svix-onelson requested a review from a team as a code owner October 29, 2024 23:42
@svix-onelson svix-onelson merged commit c4daee8 into main Oct 30, 2024
3 checks passed
@svix-onelson svix-onelson deleted the onelson/go-nullable-string branch October 30, 2024 16:24
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.

Go SDK: NullableString awkwardness
2 participants