Closed endigma closed 1 month ago
I sort of see this as the builder pattern. The problem with using the builder pattern in go is either you have to create a whole new set of objects, or you can't return error
(or you have to abuse panic()
and recover()
). I don't have too much of an issue with, although personally I find the builder pattern harder to read because I need to scan the line for the .
at the end, rather than a lined up event.
but that wasn't the reason for it's usage here.
Which is already being used that way, so it would be inconsistent:
Plus I've been using that convention to mean "new": https://github.com/arran4/golang-ical/blob/109346913e546be9f71334e3dad75e9dbbb6db84/calendar.go#L408-L412
I'm not against a PR for either:
With
or even Must
(think regexp
or text/template
)?I can't guarantee I will merge it, but I won't close it and provide feedback until it's acceptable.
I really think that for this type of pattern to work in go you would need something like: the coalesce operators ?.
from Javascript/typescript world where if the 2nd param is an error
or the output is nil, handle it.
Sorry, I'm going to close this for now. It might be possible but probably not in this way. It will likely be in a builder pattern style however I'm not sure it helps people enough.
Feel free to reopen to discuss more, or create a discussion. (What I feel is the most unused) I figure we should design this in a way it doesn't impact the existing public API.
If you write your component methods like:
instead of
The API can be used like:
which reads a little cleaner than
in my opinion
this is also not a breaking change, the API would still work the 2nd way too