#Query builder patterns for nullable fields

1 messages · Page 1 of 1 (latest)

keen cipher
#

I was having trouble following this so took the liberty of creating a thread @ruby ore @dry siren 🙂

#

I was wondering about this a while back (when writing my fantasy go DX) and the LLB pattern seemed the most natural

#

After all we're using the llb pattern for chaining too...

dry siren
#

yeah, so I think the LLB pattern is great from a code readability standpoint, my only complaint is sometimes it's hard to discover the available options. having LSP completion helps a lot since it can infer that you're trying to call a method with a e.g. RunOption return type, but it's not as simple as just setting fields on a struct.

having said all that, I still think it's probably the best choice. having to always pass in a nil options struct or nil for every optional parameter would be kind of clunky.

keen cipher
#

I've had that experience getting lost in the llb go docs

#

Maybe the pattern could be refined? For example instead of:

Directory(DirectoryID("foo"))

We could do:

Directory(DirectoryOpts().WithID("foo"))
#

meh

#

Actually why is a struct not viable? Because of string pointers being weird?

dry siren
#

a struct would be simple and really not that bad. you mean like .Directory(&DirectoryOpts{ID: "foo"})? and .Directory(nil)? I think the GitHub API works that way.

#

the only downside imo is having the nil (or worse, DirectoryOpts{}) but that's really not a big deal. and maybe we could make it a sneaky variadic arg

keen cipher
#

Yeah except it would have to be .Directory(&DirectoryOpts{ID: &"foo"}) or .Directory(&DirectoryOpts{ID: nil}) which is not as slick, as @ruby ore mentioned

#

In practice it won't be a problem for IDs, since you'd never pass a literal string as ID

#

but same problem for eg. path

dry siren
#

oh yeah true. with generics we can have a func Ptr[T any](x T) *T { return &x } - but it's still a bit clunky

#

(i think that'll end up in stdlib someday)