assert "foo"[3] != "foo"[3,1]...revisited

Discussion in 'Ruby' started by timr, Aug 23, 2010.

  1. timr

    timr Guest

    consider the following irb session;

    >> "foo"[0]

    => "f"
    >> "foo"[1]

    => "o"
    >> "foo"[2]

    => "o"
    >> "foo"[3]

    => nil
    >> "foo"[4]

    => nil

    >> "foo"[0,3]

    => "foo"
    >> "foo"[1,3]

    => "oo"
    >> "foo"[2,3]

    => "o"
    #note the following weird case!!!
    >> "foo"[3,3]

    => ""  #this should be nil in my mind, "foo"[3] is nil, and taking
    three characters is still nil.
    >> "foo"[4,3]

    => nil

    So, to summarize, when indexing a position beyond the length of a
    string, ruby returns nil. But when indexing a slice beyond the length
    of a string, ruby returns an empty string "" for the first index
    beyond and then nil.

    I don't like that this passes
    assert "foo"[3] != "foo"[3,1]

    Matz, you are so smart, but this does not follow the principle of
    least surprise!!! こんなことはへんじゃないすか。

    I would appreciate it if anyone can explain how this might make
    sense...but please only try if you really believe it is a defensible
    behavior for the language.
    timr, Aug 23, 2010
    1. Advertisements

  2. [Note: parts of this message were removed to make it a legal post.]

    2010/8/23 Yukihiro Matsumoto <>

    > ...In message "Re: assert "foo"[3] != "foo"[3,1]...revisited"
    > on Mon, 23 Aug 2010 17:51:02 +0900, timr <> writes:
    > |I don't like that this passes
    > |assert "foo"[3] != "foo"[3,1]
    > |...

    "foo"[3,1] is "" since when index is within the string, the sought
    > length will be rounded to fit in the size. And 3 (which equals to the
    > length of the string) is considered as touching the end of the string,
    > so the result length is zero.
    > ...
    > matz.

    I'm grateful for the reply, and for the question that prompted it, as that
    is something that has bothered/intrigued me for some time, and I had
    wondered whether it was something to do with string (or array) processing
    near the end of the string. I think it's worth adding something like Matz's
    wording to
    because reasons for why things work a particular way do help people (well,
    at least me) remember behaviour.

    I first noticed this when I was doing some complicated string processing,
    and was using (or trying to use) something like str[i, 1] being nil to
    indicate that the end of the string had been reached. (I could perhaps have
    used regular expressions, but I didn't - and sometimes still don't - trust
    my understanding of them, and I was very wary of an apparent regular
    expression match or non-match being not quite what I'd intended it to be.) I
    then found that arrays worked the same way.

    At the time I wondered about asking whether it might be of more general use
    if String and Array also had a variation of slice having the behaviour I
    wanted for what I was doing (that is working like slice, except when the
    index is just past the end of the string or array when it would return nil),
    but didn't pursue it, partly from assuming that since [] / slice were fairly
    fundamental parts of String and Array it was very likely this had been
    debated before, even if I couldn't find the debate.

    I'm tempted to suggest that now, partly because I would find it useful (not
    sure what to call it, but it should start with "slice") - yes, I know I
    could write something to do that for my own use! - and partly because if you
    (well I) have two similar but a little differently named methods it might
    help you (well me) remember that there is a behaviour difference to what -
    choosing my words very carefully - I am expecting. (And being well aware
    that *I* didn't invent the Ruby computer language.)

    *** off the topic of the thread, but on the topic alluded to by my last
    comments, and prompted by Matz's penultimate sentence: I'm rather
    distrustful of slogans - I think there is a danger that they start being
    used as a substitute for really thinking about things, so I was pleased when
    the use of a certain phrase in Ruby discussions became discouraged (quite a
    long time ago now). I don't use Python, but I do sometimes look at the
    discussion groups, and I get the impression that "there should only be one
    obvious way to do it" sometimes (frequently???) gets misused, not least by
    the omission of "obvious". It also illustrates nicely how slogans can get
    corrupted: looking here
    I find that (a) the original (?) version is more complex, and (b) more than
    somewhat self-deprecating, which I like, because it at least hints at the
    possibility that different people can quite reasonably take different views
    on things.
    There should be one -- and preferably only one -- obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.
    Colin Bartlett, Aug 23, 2010
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Thomas Guettler

    assert 0, "foo" vs. assert(0, "foo")

    Thomas Guettler, Feb 23, 2005, in forum: Python
    Carl Banks
    Feb 23, 2005
  2. Replies:
    John Roth
    Jul 29, 2005
  3. Alex Vinokur

    assert(x) and '#define ASSERT(x) assert(x)'

    Alex Vinokur, Nov 25, 2004, in forum: C Programming
    Keith Thompson
    Nov 25, 2004
  4. .rhavin grobert

    vector: Foo[5] == ((foo*)Foo) + 5 ?

    .rhavin grobert, Sep 23, 2008, in forum: C++
    Sep 24, 2008
  5. Replies:
    Thomas 'PointedEars' Lahn
    Dec 23, 2007

Share This Page