-
Notifications
You must be signed in to change notification settings - Fork 77
Description
@jirfag great project and I am glad I found it even though this late.
I have one question though. With respect to code readability, does it make sense to copy gorm's way of accepting a result pointer as an argument?
What I mean is the following. Every QuerySet instance has one of these methods:
func (qs UserQuerySet) All(ret *[]User) error {
return qs.db.Find(ret).Error
}I allowed myself to insert a second method that looks one idea cleaner if you are coming from other languages:
func (qs UserQuerySet) AllRet() ([]User, error) {
var ret []User
err := qs.db.Find(&ret).Error
return ret, err
}Since I don't want to make false claims, I also wrote a quick benchmark testing each and every method with the same conditions (10000 mock users benching for 5s). Here are the results:
BenchmarkUserSelectAll-8 361764 14977 ns/op 6154 B/op 100 allocs/op
BenchmarkUserSelectAllRet-8 368132 14634 ns/op 6153 B/op 100 allocs/op
Without going as far as to claim that my method is faster, I'd just say they are on par with one another. What was then the motivation to follow the result pointer approach? Could we make an improvement proposal in the future?