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

Allow structCodec to handle fields with pointer types #25

Closed
riannucci opened this issue Dec 14, 2015 · 1 comment
Closed

Allow structCodec to handle fields with pointer types #25

riannucci opened this issue Dec 14, 2015 · 1 comment

Comments

@riannucci
Copy link
Member

This would allow you to distinguish zero from not-set, and possibly allow you do do better memory management for repeated fields (slice-of-pointer is a bit more granular than slice-of-struct). Since 'nil' is actually a first-class datastore type, I don't see why this wouldn't be plausible.

It would also have the benefit of reducing the number of 'gotcha!'s by one, for folks who design datastore models.

@riannucci
Copy link
Member Author

After thinking about this more, I think the reason is the following:

type Foo struct {
  A string
  B string
}

type Bar struct {
  Foos []*Foo
}

var HowDoISerialize = &Bar{
  Foos: []*Foo{
    {"hi", "there"},
    nil,
    {"something", "else"},
  },
}

Normally without pointers, this would be serialized as:

Bar.Foos.A = "hi", "", "something"
Bar.Foos.B = "there", "", "else"

This would be indistinguishable from having a Foo in the middle with zero-valued strings. We could make the zero-value strings nil instead, but the problem is essentially the same. We'd need to introduce a new property like Bar.Foos.$present which would be an array of bools... and then it starts getting complicated :)

I'm inclined to punt on this in favor of #5 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

1 participant