Instead of exposing the fields in a struct like that, you may consider
using constructor function to have better control over what the user can
set into the struct. That way you don't need to worry about the user
setting invalid values. For instance,
```Go
type EmailEvent struct{
id string
date time.Time
description string
}
func NewEmailEvent(id string, date time.Time, description string)
EmailEvent {
return EmailEvent{id,date,description}
}
func NewEmailEventByDescription(description string) EmailEvent {
return EmailEvent{
id: randomID(), //validate or set the default value for optional or
missing fields
date: time.Now(),
description: description,
}
}
```
Or you can getter and setter methods instead of constructors.
```Go
func (e *EmailEvent) SetID(id string) {
//validate id
if id == "" {
//do something
}
}
```
Or you can set the missing value upon use.
```
func (e EmailEvent) Write(writer io.Writer) {
if e.id == "" {
e.id = randomID()
}
//do processing here
}
```
About type variant, the common way is to use interface as others have
suggested since it is easily extensible. Alternatively, you may merge them
into one struct. This is less flexible but may be useful when you are
dealing with small type variants. For example:
```Go
type EventType int
const (
Undefined EventType = iota
DisplayEvent
MailEvent
)
type Event struct {
from string
to string
description string
eventType EventType
}
func NewDisplayEvent(desc string) Event {
return Event {
description:desc,
eventType: DisplayEvent,
}
}
func NewMailEvent(from, to, desc string) Event {
return Event {
from: from,
to: to,
description: desc,
eventType: MailEvent,
}
}
//implement your getters here
```
I hope this helps.
On Friday, June 18, 2021 at 2:45:36 AM UTC+7 ba...@iitbombay.org wrote:
> On Jun 17, 2021, at 1:20 AM, Jan Mercl <0xj...@gmail.com> wrote:
> >
> > On Thu, Jun 17, 2021 at 9:43 AM Joshua <joshua.o...@gmail.com> wrote:
> >
> >> 1) I'm modelling a data type which has a field which may or may not be
> >> there, would most Gophers reach for a pointer here, and use `nil' to
> >> represent a missing value?
> >
> > That's the usual approach seen in the wild and IMO often the wrong one.
> >
> > Unless the size of the field's type is big, I'd suggest just a plain
> > field and a boolean value that represents the "present/valid"
> > information.
>
> This can get error prone as you may forget to update the validity field
> and the error may not be caught easily. And painful if you have more
> than one optional field. Now you need to invent more names or use
> longer names (foo_valid). The pointer alternative will fail more obviously
> if you mess up!
>
> >
> > Less GC pressure, improved cache locality.
> >
> > --
> > 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...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA40n-XGP2edWe1b13kpE4PhdFdCsJWGk79z8ngEpj19ycwmxQ%40mail.gmail.com
> .
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/a461c03a-df72-4d67-b0b5-7c4c1ff523ffn%40googlegroups.com.
