Deprecated Library Functions / Methods

Jonathan M Davis jmdavisProg at gmx.com
Sun Dec 2 18:46:40 PST 2012


On Monday, December 03, 2012 13:28:05 Walter Bright wrote:
> On 12/3/2012 1:00 PM, Jonathan M Davis wrote:
> > So, yes having a development and stable branch will help manage things,
> > but
> > even with that separation, we don't want to be breaking people's code due
> > to library changes.
> 
> I agree with that sentiment, but I find it to be completely at odds with
> your desire to clean up and remove clutter from Phobos whether or not
> that breaks user code.

My goal has been to clean up Phobos so that we have an API which is reasonable 
to keep as it is with minor changes, if any at all. Doing so requires breaking 
code, but once it's done, then you have a clean, stable API. Further changes 
may end up being necessary from time to time, but they'd be rare and would be 
done in a backwards compatible manner. But as long as the clean up phase is 
underway, breaking changes would be invevitable.

As such, I've been perfectly willing to break code as long as there's been 
warning given first so that people could change their code according to the API 
changes, but we're moving to a phase where that's not what we want to be doing 
anymore.

Arguably, the cleaning that has happened has taken too long, and there's still 
some left which probably needs to be cleaned up, but regardless, we need to 
start focusing on stabilizing what we have. Fortunately though, most of the 
APIs that needed fixing have been fixed, and for the most part, those that still 
need to be fixed are in modules which need to be outright replaced anyway, so 
we can use the std.xml -> std.xml2 scheme to deal with those.

It's never been the case that I've wanted to break Phobos' APIs all the time 
in order to make minor improments to them. It's just that I've wanted to clean 
them up further before stabilizing on what they'll ultimately be.

- Jonathan M Davis


More information about the Digitalmars-d mailing list