-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Counting from the end of an array #382
Comments
Well the obvious thing is to just omit an end, e.g. ma_array[x..] Some people didn't like this for one reason or another. I thought it made alot of sense and certainly beats: my_array[x...my_array.length] |
That's not a bad idea for the use case you gave, however it doesn't cover cases where we only want a single item from the list, and not a range. It also doesn't cover ranges that pull a number of items from the back of the list. Would be great if the dots had a direction attached, instead of assuming the range is always front-to-back:
|
Well reversing the list as part of the operation is probably a bad idea. This would be better.
|
Of course this notation makes it cumbersome to extract a large range from the middle of the list, e.g. everything between the first two items and the last two items. I think a simple notation denoting a zero-based index counted from the back-end is best:
|
...or if omitting an end is undesirable:
though I personally agree with weepy that allowing the omission is fine. |
I've been using my own implementation for quite some time now. It isn't the most elegant solution, but it gets the job done and as you've said, it's much better than the status quo. Unfortunately native negative indices are out of the question. I agree with weepy we should enable slices like Of the proposed syntaxes, I don't find any of them to be eye appealing. I recall there was a suggestion at one point to ditch slices in their form
and the alternative:
and there we have it -- distinguishing between expands |
We had a ticket about this a while back ... http://github.com/jashkenas/coffee-script/issues/issue/156 And, although Stan's proposal for |
I popped a comment on the end of the original ticket. In brief I really think Stan's proposal is a good one if we introduce new syntax to avoid potential confusion. E.g: |
There is an issue with the latest version of `coffee-script-source` outlined in jashkenas/coffeescript#382. The `react-rails` gemspec specifies a `~>1.9` version of `coffee-script-source`, which makes it impossible to back out of its most recent version in order to avoid the errors (for example, if you want to specify `~>1.8` in your app). This change lowers the dependency version in the `react-rails` gemspec so that a user can specify a lower working version.
There is an issue with the latest version of `coffee-script-source` outlined in jashkenas/coffeescript#382. The `react-rails` gemspec specifies a `~>1.9` version of `coffee-script-source`, which makes it impossible to back out of its most recent version in order to avoid the errors (for example, if you want to specify `~>1.8` in your app). This change lowers the dependency version in the `react-rails` gemspec so that a user can specify a lower working version.
There is an issue with the latest version of `coffee-script-source` outlined in jashkenas/coffeescript#382. The `react-rails` gemspec specifies a `~>1.9` version of `coffee-script-source`, which makes it impossible to back out of its most recent version in order to avoid the errors (for example, if you want to specify `~>1.8` in your app). This change lowers the dependency version in the `react-rails` gemspec so that a user can specify a lower working version.
I find this inelegant:
The reason this feels ugly, I think, is the repetition of the variable name.
An obvious improvement would be negative values ala Python and Ruby:
But the discrepancy between a zero-based index when counting from the front and a one-based index when counting from the back makes this potentially confusing.
If the primary goal is to remove the need to include the variable name twice, then there are many possible approaches. To make both directions zero-based, we could add a special character that denotes counting backwards from the end of the array:
Or we could simply have a symbol that takes the place of "myVariableName".length:
Which approach is best may be debatable, but all these approaches are better than the status quo.
The text was updated successfully, but these errors were encountered: