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
Default value for empty string #79
Comments
We could use a pattern similar to the database/sql#NullInt64. type Float64 struct {
Float64 float64
Valid bool // Valid is true if Float64 is not NULL
}
// VTG represents track & speed data.
// http://aprs.gids.nl/nmea/#vtg
type VTG struct {
BaseSentence
TrueTrack Float64
MagneticTrack Float64
GroundSpeedKnots Float64
GroundSpeedKPH Float64
} This is a breaking change and would require a new major version. How often does this come up? |
I like that idea even better, but I can imagine that a breaking change is too much for now Some actual data from my vessel (
|
One option is to introduce the Null types along with methods on the package main
import "github.com/adrianmo/go-nmea"
// A type to hold the parsed record
type XYZType struct {
nmea.BaseSentence
Time nmea.NullTime
Counter nmea.NullInt64
Label nmea.NullString
Value nmea.NullFloat64
}
func main() {
nmea.MustRegisterParser("XYZ", func(s nmea.BaseSentence) (nmea.Sentence, error) {
p := nmea.NewParser(s)
return XYZType{
BaseSentence: s,
Time: p.NullTime(0, "time"),
Label: p.NullString(1, "label"),
Counter: p.NullInt64(2, "counter"),
Value: p.NullFloat64(3, "value"),
}, p.Err()
})
} |
I went though the existing types and it seems like we'd only need You could then override the VGK parsing like this: package main
import "github.com/adrianmo/go-nmea"
// VTG represents track & speed data.
// http://aprs.gids.nl/nmea/#vtg
type VTG struct {
BaseSentence
TrueTrack nmea.Float64
MagneticTrack nmea.Float64
GroundSpeedKnots nmea.Float64
GroundSpeedKPH nmea.Float64
}
func main() {
nmea.MustRegisterParser("VTG", func(s nmea.BaseSentence) (nmea.Sentence, error) {
p := nmea.NewParser(s)
return VTG{
BaseSentence: s,
TrueTrack: p.NullFloat64(0, "true track"),
MagneticTrack: p.NullFloat64(2, "magnetic track"),
GroundSpeedKnots: p.NullFloat64(4, "ground speed (knots)"),
GroundSpeedKPH: p.NullFloat64(6, "ground speed (km/h)"),
}, p.Err()
})
} |
Thanks! I will use this idea in my code as I was already aliasing the VTG (and other sentences) because I needed them to implement another interface. |
@adrianmo take a look when you have a moment. |
What i noticed with the mda, mwd and mwv Type's is they have a value after each data, if that is either or not set, data before is valid or not. |
Another option, that's a bit more idiomatic, would be to make the values pointer types and use However, the nullable float and int types already suggested also seem like they'd work well. (just my two cents, I haven't hit this personally) |
Any decision on this? I feel that @icholy has a nice, non-breaking solution, no? My use-case: the GPS device only sends course over ground field if the speed is high enough to compute something meaningful. Thanks! |
@bezineb5 thanks! |
@adrianmo can you create a release? |
When a value is missing in a nmea string the float or int value in the parsed sentence is set to 0. This way it is hard to determine if the value is really 0 or the data was missing. E.g.
$GPVTG,0.3,T,,M,,N,12.6,K*78
would result inGroundSpeedKnots: 0
andGroundSpeedKPH: 12.6
. Now it is easy to guess that thatGroundSpeedKnots
is invalid, but forTrueTrack: 0.3
andMagneticTrack: 0
it is not possible.Is there a specific reason why this is done in this way?
I would suggest to add getters to the sentences for all the value like:
These getters can check an internal state for each value and return an error if the value was not available in the original nmea string. This will also not break existing code because it is still possible to use
TrueTrack
,MagneticTrack
etc directly.The text was updated successfully, but these errors were encountered: