thunk wrote in post #96851:
The details of the example did not make sense to me, among other
things I'm not using Sinatra yet. I readily confess this. But he
did say that he was looking to:
find the difference between two strings?
not just about, but EXACTLY.
Maybe the OP could have chosen a better subject heading, but it's fairly
clear you didn't read any of the actual post.
The point is, he's calling a function foo(x) where x is either a string
"bar" read from a Sinatra parameter, or a literal string "bar". The
method foo() is behaving *differently* in these two cases, even though
the strings are apparently equal. He wrote:
"Using the params[:service] variable then mymethod fails to do what I
expect. If I hard-code the string that it's supposed to represent, it
works. Every way I've examined this variable it looks exactly the same
as a hard-coded version. Dump, inspect, to_s, length, class, equality,
they all give the answer I expect - it's a String, and it is the same
string that's in the URL that's been passed."
In other words,
foo(x) != foo(y) even though x == y
Trying to use any algorithm to measure "nearness" is not going to help
when Ruby already told him the strings are equal. If you test them for
equality character-by-character, they'll still be equal.
However there was a recent similar issue, where the significant
difference was that the strings had different encodings:
The trouble is that Ruby 1.9 can say some strings are "==" when they
have the same byte content but different encodings, under some
circumstances which I won't attempt to describe here. And the hidden
encoding attribute may in turn influence the behaviour of library
functions that you call.
I would not be defensive it I had not
been called on this in such a rude fashion.
I don't condone rudeness, which has added more noise to this thread.
However you did make a thoughtless posting, apparently based on reading
only the subject line and not the content. Hence I can understand the
reaction.
···
--
Posted via http://www.ruby-forum.com/\.
