These are most frequently used in Perl to remove trailing whitespace
from a line. Go already has functions to remove whitespace from both
the front and back of a string (this removes the necessity for chomp).
If you simply want to `strip' the last character from a string:
newString := string[:len(string)-1]
This effectively removes the necessity for chop.
--dho
This is true, though I think string.chop() is _far_ more readable.
Ramanan.
Matter of taste.
func chop(s string) {
return s[:len(s)-1]
}
> Ramanan.
>
er,
func chop(s string) string {
return s[0:len(s)-1]
}
fixed.
I guess it must be a matter of taste/preference/aesthetic/whatever.
For me the former is far more readable. Here's why. To know a
_language_ does not necessarily mean knowing every one of (in some
cases an enormous number) of libraries available for it, or even the
ones identified as standard. If I truly know the language and just
happen to have memorized the particulars of chop(), then both are
equally understandable. If I know the language, but haven't memorized
that part of the string library, I can understand the first, but the
second requires me to head to the man page. If I don't know the
language, then I shouldn't be using the library until I do. In other
words, for me readable implies that I can understand exactly what it's
doing without running off to some other documentation, and for me
that's much more likely to be true of the first form than the second.
BLS
I quite like (and agree with) your explanation here. Thanks for
putting it so eloquently.
It's perhaps worth qualifying this, though: it only really holds valid
for short snippets such as this, though. Get much longer and you do
want a function: this is why they exist, and why we have packages in
the first place (this is obvious). At some level of complexity, you
have to refer to man pages or whatever the relevant documentation is.
I think there are two other things standing in the way of Chomp/Chop:
1) Nomenclature: both of these functions have very terse names and are
among the most frequently misused and misunderstood functions among
beginners in Perl. People chop when they mean chomp and vice versa. If
they were to make it into Go, I would suggest different names, and
2) Non-standard: they only really exist in Perl (and PHP, sort of, for
weak Perl-like ease-of-transition). In Python or Ruby, you would
likely be told to use right-hand trimming in place of chomp or a
similar slice-type syntax in place of chop.
--dho
> BLS
>
That's a good point. It would certainly be counterproductive to
eliminate libraries and functions altogether. And of course, once you
have libraries, man pages come along by necessity. What gets to me is
the propensity to give names to basic operations in a language under
the assumption that names are more readable than operators. It's
reminiscent of a comment like:
i++ // add 1 to i
If I'm being graded on the number of comments or I'm trying to write
example code to explain how ++ works, then maybe there's a reason for
a comment like this. Otherwise, it just clutters the code. Once
again the words of Grace Murray Hopper come to mind:
There are two kinds of people in the world. Those of us who are
basically mathematicians want to reduce all the words to symbols. The
others want to replace all the symbols with words. COBOL was created
for the second group.
BLS
func chop(s string) {
return s[:len(s)-1] // 5
}
//
./op_strings.go:5: syntax error near s
func chop(s string) string {
return s[:len(s)-1]
}
And I think the new s[:n] syntax was introduced relatively recently,
make sure you're running the latest.
A function that returns a string must return a string:
func chop(s string) string {
return s[:len(s)-1]And I think the new s[:n] syntax was introduced relatively recently,
}
make sure you're running the latest.
It's work. Thank you !
On 12 янв, 16:04, Peter Bourgon <pe...@bourgon.org> wrote:
> This is what I get for not compiling my example code :)
>
> On Tue, Jan 12, 2010 at 11:45 AM, SnakE <snake.sc...@gmail.com> wrote:
> > 2010/1/12 Peter Bourgon <peterbour...@gmail.com>
I introduced (and, 3 minutes later, fixed) the broken code. This is
what we all get when people don't read email threads they're
participating in, I guess.
--dho
it would take a set of characters and remove them from both ends of
the string.
For instance, strings.Trim ( `" hello" `, `" `) -> "hello" ( removes
the quotes and the space )
On Jan 12, 5:17 am, "Devon H. O'Dell" <devon.od...@gmail.com> wrote:
> 2010/1/12 Peter Bourgon <pe...@bourgon.org>:
>
> > This is what I get for not compiling my example code :)
>
> I introduced (and, 3 minutes later, fixed) the broken code. This is
> what we all get when people don't read email threads they're
> participating in, I guess.
>
> --dho
>
>
>
> > On Tue, Jan 12, 2010 at 11:45 AM, SnakE <snake.sc...@gmail.com> wrote:
> >> 2010/1/12 Peter Bourgon <peterbour...@gmail.com>
>
In this specific instance you'd be better off
with a real unquoter like strconv.Unquote.
Russ