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