I don't get the impression that we are going to see generics in Go anytime soon. I'll be surprised to see it before 2020. So until then, I like having a library like this even if it uses reflection.
On Tue, Nov 13, 2018 at 2:14 PM roger peppe <rogpe...@gmail.com> wrote: > It's obvious that you've put a lot of effort into this! Here's some > feedback. > > I have to say this first: this *is* a very non-Go-idiomatic API. It's > fundamentally based around reflection, and reflection in Go is generally > considered to be best avoided apart from some core libraries. Calling a > function with reflect is orders of magnitude slower than calling it > directly, and the lack of compiler type checking can make for code that's > hard to understand when it goes wrong. So I wouldn't use this in production > code. > > That said, it's a fun API and a great way to experiment with some of the > things that can be done in Go if we sacrifice compile-type type checking. > > Taking it at face value, here are a few random thoughts: > > - improve the doc comments. Go automatically generates documentation for > you (for example https://godoc.org/github.com/wesovilabs/koazee/stream) > and that's the usual place for people to read package documentation. > Everything that's exported should have a relevant doc comment. There > shouldn't be any need to generate custom API documentation. > > - avoid making public methods return private types. When a public method > returns a private type, the documentation fails because it does not display > methods on private types. > > - it's almost always better to use the builtin sort package ( > https://golang.org/pkg/sort) rather than rolling your own. > > - it's probably best not to use an arbitrary definition of equality > (stream.equalsValues), but to either use plain "==" or accept an equality > function. > > - it would be nice for it to work on arbitrary streams. This actually > isn't too hard. Here's a way of doing it that works on an arbitrary > Iterator interface, so it can iterate over channels, bufio.Scanner, etc. > https://play.golang.org/p/PXHuD1pR5uC > > Finally, if/when generics eventually make it into Go, this kind of API > will no longer have a huge overhead. I think I'd probably wait until > then... :) > > cheers, > rog. > > On Sun, 11 Nov 2018 at 19:27, Iván Corrales Solera < > ivan.corrales.sol...@gmail.com> wrote: > >> Hey guys, last weeks I've been working on Koazee and I just released a >> very first version Titi, v0.0.1 . Koazee is a golang library inspired in >> Lazy evaluation and functional programming that provides us a rich set of >> operations that can be done over arrays. If you like the clean code and the >> functional programming I am sure you enjoy it! >> >> Documentation is hosted http://wesovilabs.com/koazee/ >> >> And the full code can be found on Github, >> https://github.com/wesovilabs/koazee >> Any feedback or recommendation will be appreciated! Cheers >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- R. Mark Volkmann Object Computing, Inc. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
