<p><a href="https://github.com/cosiner/gohper">github.com/cosiner/gohper</a>.</p>
<p>The gohper package‘s structure has been fully changed, and some modules was moved to <a href="https://github.com/cosiner/ygo">github.com/cosiner/ygo</a>.</p>
<p>If some guys are using gohper, i am sorry for these changes, but it's very worthwhile to get a more clearly package.</p>
<p>The gohper package focus many libs i used in development, i am very pleased if it's helpful for community and gophers.</p>
<p>Sorry for my China English, :).</p>
<hr/>**评论：**<br/><br/>izuriel: <pre><p>The only comment I have at the moment is that your text functions should be using the Unicode package. Right now they're very dependent on ASCII encodings and sing byte characters which will probably work for most practical use cases but I think it wise to make string functions Unicode smart since runes are Unicode code points. </p></pre>tdewolff: <pre><p>Which functions do you mean? Generally, if it works for single byte characters it works for UTF-8 as well, because UTF-8 was designed with that in mind. See <a href="http://research.swtch.com/utf8" rel="nofollow">http://research.swtch.com/utf8</a></p></pre>izuriel: <pre><p>I know it can work. But take your snake case function. It only counts A-Z as uppercase. Instead, there is a Unicode method to query about the case of a code point. </p>
<p>I never said it <em>wouldn't</em> work, I just said string functions in Go should be Unicode aware. </p></pre>daveddev: <pre><p>I wrote this a while back, and would appreciate criticisms:
<a href="http://play.golang.org/p/JGIWzi5o6g" rel="nofollow">http://play.golang.org/p/JGIWzi5o6g</a></p></pre>izuriel: <pre><p>I don't see why you chose to build backwards, there is a lot of rebuilding going on with your <code>append([]rune{'_'}, buf...)</code>. Provided a sample string of:</p>
<pre><code>"SomeClass"
</code></pre>
<p>You'd end up with a (at least mental, optimizations my change this):</p>
<pre><code>append([]rune{'_'}, 'C', 'l', 'a', 's', 's')
</code></pre>
<p>Which will continue to grow if I <code>FeedItSomeLongNameThatWillSlowThingsDown</code>.</p>
<p>I, personally, would go with something along the lines of this:</p>
<pre><code>func snake(s string) string {
rs := []rune(s)
lastLower := false
buf := new(bytes.Buffer)
for _, r := range rs {
if unicode.IsLetter(r) {
if lastLower && unicode.IsUpper(r) {
buf.WriteRune('_')
lastLower = false
} else {
lastLower = true
}
}
buf.WriteRune(r)
}
return strings.ToLower(buf.String())
}
</code></pre>
<p>(further example of unicode support vs. none can be found <a href="https://play.golang.org/p/jIInNxgjCC" rel="nofollow">here</a>)</p>
<p>The real improvement here is just being more clear about what's going. By not iterating backwards and caching (via the <code>bool</code>) whether or not I'd previously encountered a 'lowercase' character I was able to reduce the if/else to a very simple branch test. Also looping forward has prevented the awkward need to append the current buffer to the end of a rune to get the new buffer. Using this method allows for <code>range</code> to work which also removes any direct array lookups from happening throughout the body of the loop.</p>
<p><strong>edit:</strong> modify sample and update link</p></pre>daveddev: <pre><p>This doesn't pass the test in my play. - <a href="http://play.golang.org/p/paOMLE_syv" rel="nofollow">http://play.golang.org/p/paOMLE_syv</a></p>
<p>If I recall correctly, working backward helped to accommodate acronyms and single caps. I think I remember not being able to nail this down until I worked "in reverse". However, it's been a while and I may be mistaken about my reasoning at that time.</p>
<p>Your time posting this is greatly appreciated! I'll dig into your function in the morning and glean as much wisdom as I can.</p>
<p>Edited to add additional test containing "SQL" - The only thing my version doesn't cover is when a single cap comes right before an acronym. I contemplated using a list of acronyms (<a href="https://github.com/golang/lint/blob/3d26dc39376c307203d3a221bada26816b3073cf/lint.go#L482" rel="nofollow">https://github.com/golang/lint/blob/3d26dc39376c307203d3a221bada26816b3073cf/lint.go#L482</a>) to aid in this issue, but wanted to keep the function light. And so far, it has not been a problem.</p>
<p>As an aside, searching for the lint list of acronyms brought me across this lib - <a href="https://github.com/serenize/snaker" rel="nofollow">https://github.com/serenize/snaker</a>
I'll look into that tomorrow as well, but I think I recall passing that over previously.</p></pre>izuriel: <pre><p>Yea I wasn't going for full on feature complete. That function doesn't handle any other form of spacing. I was just doing what you asked, providing criticisms and wanted to demonstrate the general method I would have employed with a simple example. </p>
<p>I threw in the ASCII example to strengthen my argument before you came around, that wasn't necessarily directed at you.</p>
<p>If I wasn't just giving criticisms, I think your'e solution works - the only real issue I had with it was that it wasn't immediately clear what you were doing, I had to dig in. That doesn't signify anything bad necessarily - just something I pointed out!</p></pre>Darxide-: <pre><p>As someone still relatively new to Go, it looks like a bunch of these are just rewrites of whats in the standard library? Why, what benefits are gained in some of these libraries. </p></pre>cosiner_z: <pre><p>It's not intend on rewrites, but the convenience.<br/>
Extract the common, helpful pattern, data structures, functions and components from code,
make them a second base library, that's what i do: DRY! Don't repeat yourself!<br/>
One can imagin how tedious it is to repeat yourself day by day!</p>
<p>Anyone can take codes from it and put yours to it, welcome for feedbacks and contributions.</p></pre>
