View mode: basic / threaded / horizontal-split · Log in · Help
December 02, 2012
Re: Deprecated Library Functions / Methods
On Sunday, December 02, 2012 12:26:24 Johannes Pfau wrote:
> Right now we have can't promise not to break code because
> we can't keep and support code like std.xml forever but we also can't
> simply remove std.xml because we try to avoid breaking code. So we
> deprecate small parts of modules in every release which is a pita for
> everyone. Dropping all sub-par code and fixing naming conventions in
> one release would get us a clean restart without all that cruft.

I've done a lot in the past to try and fix function names which didn't have the 
correct naming conventions or were otherwise obviously wrong (e.g. the 
functions in std.ctype returning int instead of bool as if they were C 
functions rather than D functions), but there's a limit to what we can do, and 
we've arguably taken too long to resolve a lot of these issues. There's also 
increased resistance to breaking code. Walter has _always_ been against it 
pretty much regardless of the reason, and Andrei is starting to come around to 
his way of thinking. He's even starting to balk at removing functions which 
have been deprecated even though you have to compile with -d to use them at 
all. So, I suspect that it's too late at this point to do anything like what 
you suggest. What I've already done was requested by a lot of people (e.g. 
fixing the names of the functions in std.string), but it's also resulted in a 
lot of complaints - especially from those folks trying to use D 
professionally.

And even when we've gotten away with changing things, it's rarely been the 
case that we've broken stuff immediately. Rather, we've provided new 
functionality in new names and put the old ones through the deprecation 
process. So, I'd expect that std.xml would be replaced with std.xml2 rather 
than being thrown out and immediately replaced with the new std.xml. And while 
there was some talk at one point of outright throwing out std.xml even though 
we don't have a replacement yet, and it never happened.

So, while I can sympathize with your position and to some extent agree with 
it, I think that it's too late.

- Jonathan M Davis
December 02, 2012
Re: Deprecated Library Functions / Methods
On Sunday, 2 December 2012 at 12:15:57 UTC, Jonathan M Davis 
wrote:
> On Sunday, December 02, 2012 12:26:24 Johannes Pfau wrote:
>> Right now we have can't promise not to break code because
>> we can't keep and support code like std.xml forever but we 
>> also can't
>> simply remove std.xml because we try to avoid breaking code. 
>> So we
>> deprecate small parts of modules in every release which is a 
>> pita for
>> everyone. Dropping all sub-par code and fixing naming 
>> conventions in
>> one release would get us a clean restart without all that 
>> cruft.
>
> I've done a lot in the past to try and fix function names which 
> didn't have the
> correct naming conventions or were otherwise obviously wrong 
> (e.g. the
> functions in std.ctype returning int instead of bool as if they 
> were C
> functions rather than D functions), but there's a limit to what 
> we can do, and
> we've arguably taken too long to resolve a lot of these issues. 
> There's also
> increased resistance to breaking code. Walter has _always_ been 
> against it
> pretty much regardless of the reason, and Andrei is starting to 
> come around to
> his way of thinking. He's even starting to balk at removing 
> functions which
> have been deprecated even though you have to compile with -d to 
> use them at
> all. So, I suspect that it's too late at this point to do 
> anything like what
> you suggest. What I've already done was requested by a lot of 
> people (e.g.
> fixing the names of the functions in std.string), but it's also 
> resulted in a
> lot of complaints - especially from those folks trying to use D
> professionally.
>
> And even when we've gotten away with changing things, it's 
> rarely been the
> case that we've broken stuff immediately. Rather, we've 
> provided new
> functionality in new names and put the old ones through the 
> deprecation
> process. So, I'd expect that std.xml would be replaced with 
> std.xml2 rather
> than being thrown out and immediately replaced with the new 
> std.xml. And while
> there was some talk at one point of outright throwing out 
> std.xml even though
> we don't have a replacement yet, and it never happened.
>
> So, while I can sympathize with your position and to some 
> extent agree with
> it, I think that it's too late.
>
> - Jonathan M Davis

Why not let all breaking improvements go to a clear cut std2 and 
let std be improved only with extensions and bug fixes? When std2 
is ready enough, let the same happen and breaking code goes to 
std3.

Then you get std.xml and std2.xml, which are different and a 
probable source of confusion. On the other hand, the modules in 
the standard library do not exist independently, they are part of 
a unified design and layout. So it may be more valuable to know 
that std3.algorithm, std3.range, std3.container, etc. work 
together out of the box, rather than to know whether 
std.algorithm2 and std.range3 are compatible.

Each library should additionally depend on a specific stable 
release of D, as discussed recently. (All library bug fixes and 
extensions are based on that specific release).

Thoughts?
December 02, 2012
Re: Deprecated Library Functions / Methods
On 2012-12-02 00:47, sclytrack wrote:

> The problem with sticking to a certain version is that all the third
> party libraries are sticking to a previous or next version (eh ...
> sometimes same version). Requiring slight modifications for every
> (eh...) third party library.

Yeah, there's no silver bullet that solves all the problems.

-- 
/Jacob Carlborg
December 02, 2012
Re: Deprecated Library Functions / Methods
On Sunday, December 02, 2012 14:19:18 deed wrote:
> Why not let all breaking improvements go to a clear cut std2 and
> let std be improved only with extensions and bug fixes? When std2
> is ready enough, let the same happen and breaking code goes to
> std3.
> 
> Then you get std.xml and std2.xml, which are different and a
> probable source of confusion. On the other hand, the modules in
> the standard library do not exist independently, they are part of
> a unified design and layout. So it may be more valuable to know
> that std3.algorithm, std3.range, std3.container, etc. work
> together out of the box, rather than to know whether
> std.algorithm2 and std.range3 are compatible.
> 
> Each library should additionally depend on a specific stable
> release of D, as discussed recently. (All library bug fixes and
> extensions are based on that specific release).
> 
> Thoughts?

Duplicating the entire standard library is overkill. Ideally, we wouldn't need 
to keep making breaking changes to it. You get it right, and then you leave it 
as-is. The main problem is that Phobos has been being written as the language 
has been evolving.. That means that we have old stuff that doesn't follow how 
things are done now (e.g. the naming conventions or being range-based). Once 
that's fixed, you don't need to keep fixing it. Only a few modules need major 
overhauls. Most of them have already had it or have been deemed fine. So, 
there's not much point in setting up a scheme like std2.*. Rather, it makes 
_far_ more sense to just replace the modules that need replacing.

Also, remember that we're trying to minimize code breakage, and requiring that 
every single import to the standard library get changed periodically goes 
against that completely. Not to mention, it's not like we want multiple 
versions of the thing floating around. It's far better to just have those 
people who use std.xml update their code once std.xml2 is out, and then we 
phase out std.xml. With your suggestion _everyone_ would have to change their 
code when that happened.

And it's not like different modules are incompatible with other modules in the 
standard library even if we want to replace some of them. The fact that 
std.xml isn't range-based does not mean that it doesn't work with the rest of 
Phobos. And when std.xml2 comes along, it'll work with whatever verson of 
Phobos is current at the time. The only versioning that's required as far as 
module compatibility goes is the compiler release, because druntime and Phobos 
are versioned with it as well.

- Jonathan M Davis
December 02, 2012
Re: Deprecated Library Functions / Methods
On 12/2/2012 11:52 AM, Jonathan M Davis wrote:
> We _were_ looking at outright throwing std.xml away at one point and then
> replacing it later, given how bad it is, but we never quite did that, and at
> this point, I wouldn't expect it to happen. We've been focusing more on
> avoiding breaking code of late, and so, doing something like that probably
> wouldn't be deemed acceptable at this point.

For this case (and others like it) I strongly suggest putting the revamp 
in something called std.xml2, and keep std.xml, but let std.xml wither 
and die away of its own accord rather than killing it.

For example, after a while it can be removed from the web site 
documentation.
December 02, 2012
Re: Deprecated Library Functions / Methods
On 12/2/2012 10:26 PM, Johannes Pfau wrote:
> Avoiding breaking code is always a good goal, but I think it's too
> early for phobos. Code like std.xml, std.outbuffer should have never
> been a part of phobos. I think one last big break would be best for
> everyone.

No, no, no!


> Right now we have can't promise not to break code because
> we can't keep and support code like std.xml forever

Yes, we can (or at least for a very long time).

> but we also can't
> simply remove std.xml because we try to avoid breaking code. So we
> deprecate small parts of modules in every release which is a pita for
> everyone. Dropping all sub-par code and fixing naming conventions in
> one release would get us a clean restart without all that cruft.

No, it won't, because names are a bikeshedding thing and every group of 
name changes spawns more name change proposals. Every big break (and 
we've done them before) spawns more big break proposals. We have to stop 
doing this, or D will never ever advance.

The existence of std.xml that is ignored and left out of the 
documentation is not going to discourage people from using D, but 
constantly telling people they have to rewrite their existing, working, 
and stable code will, as the start of this thread shows.
December 02, 2012
Re: Deprecated Library Functions / Methods
On Monday, December 03, 2012 08:28:30 Walter Bright wrote:
> On 12/2/2012 11:52 AM, Jonathan M Davis wrote:
> > We _were_ looking at outright throwing std.xml away at one point and then
> > replacing it later, given how bad it is, but we never quite did that, and
> > at this point, I wouldn't expect it to happen. We've been focusing more
> > on avoiding breaking code of late, and so, doing something like that
> > probably wouldn't be deemed acceptable at this point.
> 
> For this case (and others like it) I strongly suggest putting the revamp
> in something called std.xml2, and keep std.xml, but let std.xml wither
> and die away of its own accord rather than killing it.
> 
> For example, after a while it can be removed from the web site
> documentation.

That's basically what I'd expect to happen with this.

And if you accept dmd pull# 1287, then that's probably how deprecation will be 
handled in general in the long term. Without that, I'm not sure what we're 
going to do, since then deprecating _anything_ breaks code.

Regardless, there's some stuff that's already been deprecated which probably 
should be outright removed at some point here (e.g. the deprecated functions 
in std.string which don't follow the correct naming conventions), but once 
that sort of thing has been removed, I think that we should be moving to a 
model where deprecated stuff becomes undocumented and withers away only to be 
outright removed with a major release of some kind. Such removals could be 
made to fit into the stable branch model somehow, but the deprecated symbols 
would be around a long time before being removed with a major release, and 
depending, we may not even remove them then. But as deprecations should be 
becoming rarer as the library stabilizes, this should be less of an issue.

- Jonathan M Davis
December 02, 2012
Re: Deprecated Library Functions / Methods
On Sunday, 2 December 2012 at 21:37:17 UTC, Walter Bright wrote:
> On 12/2/2012 10:26 PM, Johannes Pfau wrote:
>> Avoiding breaking code is always a good goal, but I think it's 
>> too
>> early for phobos. Code like std.xml, std.outbuffer should have 
>> never
>> been a part of phobos. I think one last big break would be 
>> best for
>> everyone.
>
> No, no, no!
>
>
>> Right now we have can't promise not to break code because
>> we can't keep and support code like std.xml forever
>
> Yes, we can (or at least for a very long time).
>
>> but we also can't
>> simply remove std.xml because we try to avoid breaking code. 
>> So we
>> deprecate small parts of modules in every release which is a 
>> pita for
>> everyone. Dropping all sub-par code and fixing naming 
>> conventions in
>> one release would get us a clean restart without all that 
>> cruft.
>
> No, it won't, because names are a bikeshedding thing and every 
> group of name changes spawns more name change proposals. Every 
> big break (and we've done them before) spawns more big break 
> proposals. We have to stop doing this, or D will never ever 
> advance.
>
> The existence of std.xml that is ignored and left out of the 
> documentation is not going to discourage people from using D, 
> but constantly telling people they have to rewrite their 
> existing, working, and stable code will, as the start of this 
> thread shows.

And how do you conciliate that with dropping every new stuff 
directly into master ?
December 02, 2012
Re: Deprecated Library Functions / Methods
On 12/3/2012 8:41 AM, Jonathan M Davis wrote:
> Regardless, there's some stuff that's already been deprecated which probably
> should be outright removed at some point here (e.g. the deprecated functions
> in std.string which don't follow the correct naming conventions),

I do not see a compelling reason to remove them. Just leave them deprecated.

> but once
> that sort of thing has been removed, I think that we should be moving to a
> model where deprecated stuff becomes undocumented and withers away only to be
> outright removed with a major release of some kind. Such removals could be
> made to fit into the stable branch model somehow, but the deprecated symbols
> would be around a long time before being removed with a major release, and
> depending, we may not even remove them then. But as deprecations should be
> becoming rarer as the library stabilizes, this should be less of an issue.
December 02, 2012
Re: Deprecated Library Functions / Methods
On 12/3/2012 8:43 AM, deadalnix wrote:
> And how do you conciliate that with dropping every new stuff directly
> into master ?

I think you're baiting me :-) but I'll respond with that is an 
orthogonal issue and belongs in the other threads for that topic.

I feel the same way about breaking code with language changes as I do 
for breaking library changes.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home