You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would love to have some discussion on the Public API. Specifically I want to know if having types with methods in addition to the functions makes sense. I think it does but maybe having two ways to do something is confusing to some. Here's what I mean by two ways of doing things:
var data = []float64{1, 2, 3, 4, 4, 5}
median, _ := stats.Median(data)
fmt.Println(median) // 3.5
var d stats.Float64Data = data
median, _ = d.Median()
fmt.Println(median) // 3.5
Please share your thoughts with me!
The text was updated successfully, but these errors were encountered:
Stubbled across this package hunting for statistics functions that operate over a slice of time.Duration, and retains the time unit in the return value. Anyway, thought I'd share my thoughts on your question about the public API.
My take is that it is best to have one way to do it, rather than many (as in the infamous Perl language). I believe this is also the Go standard library philosophy. For example, if you look at the bytes package, you will find a lot of functions that take a []byte, but none of those functions have an equivalent method based implementation. Similarly, the methods that operate on a Buffer object, are not repeated in the form of functions that take a Buffer as argument.
My suggestion would be to drop support for method invoke, and keep the function call approach.
Would love to have some discussion on the Public API. Specifically I want to know if having types with methods in addition to the functions makes sense. I think it does but maybe having two ways to do something is confusing to some. Here's what I mean by two ways of doing things:
Please share your thoughts with me!
The text was updated successfully, but these errors were encountered: