Move away from pointers for badge field?

[nathany]

The only problem with using a series of pointers in structs is they can end in race conditions if any goroutines mutate the underlying pointer.

For that reason, I took the same approach here for omitempty badges: joekarl/go-libapns#8

It's not "pretty" but it's thread-safe. @themartorana

[nathany]

This would be similar to the NullInt64 type in the sql package. 👍

[taylortrimble]

👍

[nathany]

Before the PR from @themartorana, go-libapns was just using -1 to reset the badge rather than 0 (which is omitted, meaning no change).

anachronistic/apns uses an interface for different types of Alerts. That could be another option for the badge.

[themartorana]

The biggest issue I had with -1 is that the struct is initialized with 0, a valid (and badge-clearing) value. So unless you hide the struct but give it a public initializer method, its default state is to clear the badge.

[themartorana]

Ping on this - looks like we're still using a pointer. I can quickly submit a NullInt64-esque solution like joekarl/go-libapns#8 (my preferred method). Thoughts?

[taylortrimble]

Go for it!

On Thu, Sep 3, 2015 at 12:32 PM, David Martorana notifications@github.com
wrote:

Ping on this - looks like we're still using a pointer. I can quickly submit a NullInt64-esque solution like joekarl/go-libapns#8 (my preferred method). Thoughts?

Reply to this email directly or view it on GitHub:
#38 (comment)

[nathany]

closed with #60