On Tuesday, September 06, 2011 08:42:14 Jacob Carlborg wrote: > On 2011-09-06 08:00, Walter Bright wrote: > > On 9/5/2011 7:48 PM, Andrei Alexandrescu wrote: > >> I agree with all of the above. However, as is often the case, there's > >> more than > >> one side to the story. > >> > >> Bad APIs have their costs too. We can't afford to have an XML library > >> that > >> offers few and badly packaged features and comes at the tail of all > >> benchmarks. > >> We also can't afford a JSON library that is poorly designed and badly > >> written. > >> Ironically, the costs mostly manifest the same way: people will decide > >> not to > >> use D because it "lacks good libraries" and "is quirky to use". In > >> many ways a > >> language's standard library is a showcase of the language, and to a > >> newcomer an > >> inconsistent and awkward standard library affects the perception of > >> the > >> language's quality. > > > > I agree that the XML and JSON libraries need to be scrapped and > > rewritten. But simply changing the names of otherwise successful APIs is > > not worth while. > > So we have to live with these naming conventions from C forever?
My take on it is that we need to figure out which pieces of Phobos need to be reworked or renamed and get it done as soon as possible. That way, everything follows the proper naming conventions (thus avoiding a mess like PHP) and is of an appropriately high level of quality. Then we can have an appropriately stable API which doesn't have to change often - if at all. I think that the current problem with Phobos is primarily a combination of three things: 1. Older APIs which aren't in line with how D2 and Phobos have evolved (e.g. they don't use ranges when they should). 2. Some older stuff didn't get a thorough enough peer review before making it into Phobos and is not at a high enough level of quality, so it needs to be revised or replaced. 3. Too much of what has been done in the past has been a hodgepodge of naming conventions, making it very inconsistent in some places. Once those have been sorted out (some of which can be done without breaking any existing code and some of which requires breaking changes), then we can have a stable API for Phobos which doesn't change much except where we're adding new functionality which doesn't break existing code. So ultimately, we _will_ have a stable API, but some breaking changes are required in the short term to resolve issues with Phobos which would cause problems in the long run. - Jonathan M Davis