3 ms·
Hi @ImJasonH, I Developed this, let me answer you points :) I believe these points are not contributing in breaking API :D so lets talk on them first. 2. You
by pravj 12y ago
Hi @ImJasonH, I Developed this, let me answer you points :)
I believe these points are not contributing in breaking API :D so lets talk on them first.
2. You mean instead of an array I'm using here [1], We should add them as constants and write separate documentation for each?
This sounds nice as it will help obviously like you said.
3. Ohh, I missed this convention, thanks for pointing this out. :)
4. As you said its more of a judgement call, I believe that RGB strings are fine and easy for users. You find any wrong in RGB strings?
So, I'll be very happy to co-operate if you are doing pull request covering points 2 and 3 :)
And I'll try to cover your point 1 on my own :)
Cheers \o/
[1] https://github.com/pravj/geo_pattern/blob/master/pattern/pattern.go#L17 https://github.com/pravj/geo_pattern/blob/master/pattern/pat...
- pdpi 12y agoRegarding 4, I personally tend to be distrustful of what is often described as Stringly Typed code. To me, statically constraining your API to only accept valid inputs seems like superior design.
- infogulch 12y agoIf you're reworking your API, you may want to consider functional options: http://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis http://dave.cheney.net/2014/10/17/functional-options-for-fri... I haven't attempted it myself, but it looks very interesting.
- betamike 12y agoAnother minor nitpick, here [1] you are using reflection. You can pretty easily convert it to a type switch [2], which is more idiomatic. [1] https://github.com/pravj/geo_pattern/blob/master/svg/svg.go#L81 https://github.com/pravj/geo_pattern/blob/master/svg/svg.go#... [2] https://golang.org/doc/effective_go.html#type_switch https://golang.org/doc/effective_go.html#type_switch