In general, I think that *T isn't a bad way to represent "maybe
there's a T here". The down sides of this representation are creation
(no easy to make a pointer to an int value inline without a helper
function), aliasing (if you copy the container, you haven't copied the
T value too) and cache unfriendliness (the T is likely to be stored
somewhere far away from its container).
One could imagine a Go with generics, in which it would be
straightforward to do something like:
type Maybe<T> struct {
x T
valid bool
}
func (m Maybe) Get() (m.T, bool) {
return m.x, m.valid
}
func (m Maybe) MustGet() m.T {
if !m.valid {
panic("no value")
}
return m.x
}
func (m *Maybe) Set(x m.T) {
m.x, m.valid = x, true
}
func Just<T>(x T) Maybe<T> {
return Maybe<T>{x, true}
}
In the meantime, to address the first down side at least, if I need to
create a few *int instances, I usually write a tiny helper function:
func newInt(i int) *int {
return &i
}
which at least makes creating them painless.
On 21 August 2017 at 08:44, Henry <henry.adisuma...@gmail.com> wrote:
> In my opinion, if you need a nullable type, you're entering a domain problem.
> You are better off creating your own ADT (abstract data type) with more
> descriptive names rather than "int?" or "float?".
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
