-
-
Notifications
You must be signed in to change notification settings - Fork 15
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
Remove start & end from range options #86
Comments
I would still favor a soft deprecation, so we don't surprise anyone, but if you want to go ahead and remove it right away that should work too I guess |
@juliangruber It'll be released as semver-major across the board, with the usual changelogs and upgrade guides. For the folks that missed both the 5-year-long documented notice and the upgrade guides, we'll throw an error. I think that's more than enough. |
This will greatly simplify the leveldown C++ code. |
An error is now thrown when an iterator is created with one of these options. Ref Level/community#86
An error is now thrown when an iterator is created with one of these options. Ref Level/community#86
Work is tracked in #98. |
Removes legacy ranges options (Level/community#86).
Removes legacy range options (Level/community#86).
Removes legacy ranges options (Level/community#86).
Removes legacy ranges options (Level/community#86). Cherry-picked from Level/leveldown@15d5a9e
- Removes legacy range options (Level/community#86) - Drops legacy runtime environments (Level/community#98) - In browsers, `process.nextTick()` has been replaced with `queue-microtask`
I propose that we remove the
start
andend
options from iterators & streams. Without doing a soft deprecation, because they were documented as legacy options 5 years ago. I prefer ripping off the band aid and throwing an error ifstart
orend
properties are present inoptions
.@Level/core Anyone opposed? Give a thumbs up or down. Keep reading for the motivation.
The
start/end
options are more surprising in reverse mode. Whileltgte
options fulfill the documented promise of "the returned entries are the same, but in reverse",start/end
options must be swapped by the user to achieve that.The relevant code to handle the whole set of options - which I think in many implementations has been built up through trial & error, putting trust in the extensive tests - is hard to follow, and hard to change.
In addition, there are rules of precedence between
start/end
andltgte
although a formal decision was never made (Level/abstract-leveldown#70) and tests don't cover it.The text was updated successfully, but these errors were encountered: