3 ms·

> RBTree has been removed from the collections module in favor of RedBlackTree. > direction has been removed from the collections module in favor of Direction.

> RBTree has been removed from the collections module in favor of RedBlackTree. > direction has been removed from the collections module in favor of Direction. > CSVStream has been removed from the encoding module in favor of CsvStream Hmm I smell an interesting story here. If it's renaming for the sake of renaming then that's kinda dumb and breaks backwards compat for no reason, but presumably there's a better reason somewhere?

deleted 4y ago
[deleted]
kitsonk 4y ago
std library is still considered "unstable" and the sub modules contained in there tend to have their own lifecycle as well. There has been effort to try to mature std to get to a stable version, which means cleaning up lots of things that would detract from long term maintainability.
simlevesque 4y ago
Node.js before v1 (maybe even until v4) was like this. It took like 5 years.
KyleJune 4y ago
At least for the ones related to trees, it's just a renaming. Below is a link to the PR. When I initially implemented these trees, I chose the names BSTree and RBTree to keep the names short. I'm guessing the person that proposed renaming them did so to make it more obvious what they are. https://github.com/denoland/deno_std/pull/2400 https://github.com/denoland/deno_std/pull/2400 The standard library is separate from the runtime. It wouldn't break backward compatibility if you were to update. For example, if you were importing RBTree and upgraded Deno to the latest release, it would keep working just fine. You would only really need to switch to using RedBlackTree instead if there was a change made to it that you wanted. I think the only time you would need to update your standard module imports to be able to use newer versions of the Deno runtime would be if the standard module was depending on runtime APIs that have a breaking change.

deleted 4y ago

[deleted]

kitsonk 4y ago

std library is still considered "unstable" and the sub modules contained in there tend to have their own lifecycle as well. There has been effort to try to mature std to get to a stable version, which means cleaning up lots of things that would detract from long term maintainability.

simlevesque 4y ago

Node.js before v1 (maybe even until v4) was like this. It took like 5 years.

KyleJune 4y ago

At least for the ones related to trees, it's just a renaming. Below is a link to the PR. When I initially implemented these trees, I chose the names BSTree and RBTree to keep the names short. I'm guessing the person that proposed renaming them did so to make it more obvious what they are. https://github.com/denoland/deno_std/pull/2400 https://github.com/denoland/deno_std/pull/2400 The standard library is separate from the runtime. It wouldn't break backward compatibility if you were to update. For example, if you were importing RBTree and upgraded Deno to the latest release, it would keep working just fine. You would only really need to switch to using RedBlackTree instead if there was a change made to it that you wanted. I think the only time you would need to update your standard module imports to be able to use newer versions of the Deno runtime would be if the standard module was depending on runtime APIs that have a breaking change.