4 ms·

I am not sure the author's solution, removing the said libs, is the right direction. I agree that the stdlib is crufty and slow, but they do 'work', and people

I am not sure the author's solution, removing the said libs, is the right direction. I agree that the stdlib is crufty and slow, but they do 'work', and people certainly use them. I think the better option might be to deprecate and replace.

bryanlarsen 16y ago
Unfortunate choice of wording on the authors part, because it makes it seem like your solution is less drastic than his, whereas your solution is actually more drastic. To quote the author: "removal means move to a rubygem".
rmoriz 16y ago
To me the Stdlib API looks unfixable. So imho there's only one way: * put the existing stdlib into a legacy gem * create a new stdlib with a new, good, (incompatible) API from scratch * deal with the incompatibilities that will happen
- bobbywilson0 16y ago
  I am not opposed to your solution, but sadly, I think it would be an extremely rare case. The ruby core team is very conservative with change, and I don't see some sweeping stdlib switch happening. James Edward Gray II was successful with ousting CSV for his improved implementation, and I think that's probably the way it will happen, if anything does happen. One library at a time.
- vorador 16y ago
  This article should be of interest to you (it's about rewriting from scratch) : http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
tenderlove 16y ago
Hi, I agree, deprecate and replace is the way to go. That's what I'm doing with Psych and with Fiddle. I really like this option because I don't want to break people's code. There is a downside though. I've tried shoehorning the REXML api on top of Nokogiri. The problem is that doing that work is thankless and not very fun. The API for REXML is just too large, and the deviations between the way it works and how libxml2 works are too many. I think if we add new libraries, and encourage people to move to the new ones, then start removing the old ones, that would be best.

bryanlarsen 16y ago

Unfortunate choice of wording on the authors part, because it makes it seem like your solution is less drastic than his, whereas your solution is actually more drastic. To quote the author: "removal means move to a rubygem".

rmoriz 16y ago

To me the Stdlib API looks unfixable. So imho there's only one way: * put the existing stdlib into a legacy gem * create a new stdlib with a new, good, (incompatible) API from scratch * deal with the incompatibilities that will happen

bobbywilson0 16y ago
I am not opposed to your solution, but sadly, I think it would be an extremely rare case. The ruby core team is very conservative with change, and I don't see some sweeping stdlib switch happening. James Edward Gray II was successful with ousting CSV for his improved implementation, and I think that's probably the way it will happen, if anything does happen. One library at a time.
vorador 16y ago
This article should be of interest to you (it's about rewriting from scratch) : http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html

tenderlove 16y ago

Hi, I agree, deprecate and replace is the way to go. That's what I'm doing with Psych and with Fiddle. I really like this option because I don't want to break people's code. There is a downside though. I've tried shoehorning the REXML api on top of Nokogiri. The problem is that doing that work is thankless and not very fun. The API for REXML is just too large, and the deviations between the way it works and how libxml2 works are too many. I think if we add new libraries, and encourage people to move to the new ones, then start removing the old ones, that would be best.