undefined | Better HN

0 pointst-writescode2mo ago0 comments

Sorry, I mis-spoke earlier, this is what I should have shared:

  [].slice(5, 100)

^-- *THIS* either returns nil or throws an exception.

Edit: Longer example:

  puts "[1, 2, 3].slice(1, 100) -> #{[1, 2, 3].slice(1, 100).to_s}"
  puts "[1, 2, 3].slice(3, 100) -> #{[1, 2, 3].slice(3, 100).to_s}"
  puts "[1, 2, 3].slice(4, 100) -> #{[1, 2, 3].slice(4, 100).to_s}"

Yields:

  [1, 2, 3].slice(1, 100) -> [2, 3]
  [1, 2, 3].slice(3, 100) -> []
  [1, 2, 3].slice(4, 100) ->

So, there is a behavior difference between "array a little too short" and "array slightly more too short" that creates unexpected behavior.

That's not a big surprise in a tiny example like this; but if you expand this out into a larger code base, where you're just being an array and you want the 100 through 110th values for whatever reason - say it's a csv. Suddenly you're having to consider both the nil case and the empty array case; but then why are they different?

puts "[1, 2, 3].slice(1, 100) -> #{[1, 2, 3].slice(1, 100).to_s}" puts "[1, 2, 3].slice(3, 100) -> #{[1, 2, 3].slice(3, 100).to_s}" puts "[1, 2, 3].slice(4, 100) -> #{[1, 2, 3].slice(4, 100).to_s}"

0 comments

5 comments · 2 top-level

saghm2mo ago· 2 in thread

Interesting! From playing around with it, seems like if the start index is exactly the same as the length, it returns empty array, but if it's further than that it returns nil. That's certainly not something I would have been able to predict, so I'd also be curious if anyone happens to know the explanation for it. My instinct is that it does seem like the type of edge case that might come up with a way to implement it tersely, but that's not a particularly good reason to leak that in the form of user-facing behavior, so hopefully there's a better explanation.

Some additional things I discovered when trying to figure out why it might work like that:

    * the behavior also seems consistent whether using `array.slice(a, b)` or `array[a..b]`
    * `array[array.length]` and `array[array.length + 1]` both return nil

weaksauce2mo ago

the docs say... if index is out of range return nil. the edge case is that if you specify the exact end index of the array and want a slice of that index to 100 it will return an empty array. if you go out of bounds it informs you that you are out of bounds with nil. not sure it's the best api but probably is mimicking some C api somewhere as a lot of ruby does that. that said it will never error on this alone but it will almost certainly error if you chain it with something not expecting nil.

The easiest way to get around that if you are not carefully using the ranges would be to do `Array(array.slice(a, b))` as that will guarantee an array even if it's invalid. you could override slice if you really wanted to but that would be a performance penalty if you are doing it often.

t-writescodeOP2mo ago

Indeed. I had heard that it was a carryover from C; but for an "implicit is better than explicit" and "magic ducktyping, it just works, I promise" language, like Ruby, this feels like a direct contradiction to its intended behavior and this specific example has always stood out to me in a "... but why?" sort of way.

1 more reply

weaksauce2mo ago· 1 in thread

looked into it more and the docs say that an index out of bounds will return nil. also says if offset == size and length >= 0 it will return an empty array.

``` If offset == self.size and size >= 0, returns a new empty array.

If size is negative, returns nil. ```

either way if you are doing stuff with arrays and not checking bounds you can throw an `Array(some_array.slice(x, x+100))` and it will always behave.

saghm2mo ago

Sure, the docs seem to be accurate, but that only explains "what will this do?", not "why is this what it will do?" It's not what I expect most people would come up with if they designed this API, so I have to wonder why they didn't pick something more intuitive

j / k navigate · click thread line to collapse