Right. I'm not arguing for insisting on perfect backwards
compatibility, even at the source level. I also don't think binary
backwards compatibility is worth any effort at all yet (and it's largely
moot since Phobos is mostly templates). I'm just saying that we don't
want to completely ignore the issue anymore. If you're going to make
breaking changes and there's an easy way to mitigate the breakage, then
the breakages should be mitigated. If there's no easy way to mitigate
it, then advance notice should be given. Given that the aliases have
been included, I completely support the changes that have been made.
On 11/16/2010 7:29 PM, Jonathan M Davis wrote:
On Tuesday, November 16, 2010 13:01:47 David Simcha wrote:
Once again, *please* put the aliases in for the old names for a few
releases. I'm getting really, really sick of having my code break every
release now that D2 is supposed to be "stable" and I think other D users
are starting to feel the same way.
I think that it should be general policy to use deprecated aliases where
appropriate to reduce code breakages due to changes in Phobos, but since we're
far from API stability, we're going to get breakages, and I really don't think
that it's clear outside of anyone really paying attention to D development that
Phobos is as unstable and immature as it is. It's definitely improving, but
backwards incompatible changes do occur and will continue to occur for at least
a little while regardless of the state of the compiler (e.g.
std.file.lastModified() will presumably changed to return a std.datetime.SysTime
was std.datetime has been approved, and you _can't_ make that change in a way
that supports a deprecated backwards-compatible solution since it's only the
return value that changes).
In any case, I think that your point is a good one that we should try and only
break code old code when it makes good sense to do so, and deprecated aliases
can be a good way to reduce such breakages. Eventually, we'll likely have to
move to a release cycle with major and minor releases where such breakages are
only permitted in major releases, but that's a ways off yet I think.
- Jonathan M Davis
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
