View mode: basic / threaded / horizontal-split · Log in · Help
December 02, 2012
Re: Deprecated Library Functions / Methods
On 12/1/2012 4:47 AM, bearophile wrote:
> In another thread people are discussion a solution that will help you, a
> "Stable D", updated only once in a time, like every 6-8-12 months, that
> has no know regressions and where only nonbreaking changes are allowed
> (here Phobos modules deprecations are probably to be intended as
> breaking changes).

I don't view the stable/dev branches of D as being a license to break 
existing code. Breaking code in the dev version should only be done if 
there's a very large benefit/cost ratio.

Not for bikeshedding reasons, and not if there's a way we can keep the 
old behavior around.
December 02, 2012
Re: Deprecated Library Functions / Methods
On Monday, December 03, 2012 09:25:08 Walter Bright wrote:
> 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.

They're clutter, and they've been deprecated for a while, which means that no 
one has been able to use them without -d for a while. It's also trivial to fix 
code which uses them, because they're primarily naming changes. It's just not 
worth keeping that kind of clutter around in the library IMHO. And the 
documentation has made it clear that they were going to be removed.

- Jonathan M Davis
December 02, 2012
Re: Deprecated Library Functions / Methods
On 12/3/2012 10:13 AM, Jonathan M Davis wrote:
> On Monday, December 03, 2012 09:25:08 Walter Bright wrote:
>> 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.
>
> They're clutter, and they've been deprecated for a while, which means that no
> one has been able to use them without -d for a while. It's also trivial to fix
> code which uses them, because they're primarily naming changes. It's just not
> worth keeping that kind of clutter around in the library IMHO. And the
> documentation has made it clear that they were going to be removed.

This is really the crux of our disagreement. I do not see a problem with 
leaving "clutter" around if it prevents breaking existing code. It being 
trivial to fix user code is not good enough - the fact that the user has 
to go back and fix stable, working, debugged code is the problem that 
Chris is saying is preventing him from using D seriously.

Remove them from the documentation, ok, but leave them there. It does 
not hurt to do so. Let them die on their own, we do not need to push 
them out the airlock.
December 02, 2012
Re: Deprecated Library Functions / Methods
On Monday, December 03, 2012 10:32:55 Walter Bright wrote:
> On 12/3/2012 10:13 AM, Jonathan M Davis wrote:
> > On Monday, December 03, 2012 09:25:08 Walter Bright wrote:
> >> 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.> 
> > They're clutter, and they've been deprecated for a while, which means that
> > no one has been able to use them without -d for a while. It's also
> > trivial to fix code which uses them, because they're primarily naming
> > changes. It's just not worth keeping that kind of clutter around in the
> > library IMHO. And the documentation has made it clear that they were
> > going to be removed.
> This is really the crux of our disagreement. I do not see a problem with
> leaving "clutter" around if it prevents breaking existing code. It being
> trivial to fix user code is not good enough - the fact that the user has
> to go back and fix stable, working, debugged code is the problem that
> Chris is saying is preventing him from using D seriously.
> 
> Remove them from the documentation, ok, but leave them there. It does
> not hurt to do so. Let them die on their own, we do not need to push
> them out the airlock.

Then we're definitely going to disagree. Ideally, no deprecated code would 
stick around long term. But that creates a practical problem as we do need 
code to be able to continue to compile for a very long time even if it's not 
updated, so we do often need to keep deprecated code around long term. In this 
case, however, we're talking about changes which have long since broken code 
and which were part of a major shift when cleaning up the library. The only 
code which would be using them at this point is code that hasn't been updated 
in quite some time, and so much has changed in both the compiler and the 
library since those changes were made, that it's not likely that code that old 
would still work anyway.

With an appropriately stable language and API, deprecations can and should 
take a very long time and possible stick around permanently. But neither the 
language nor the standard library has been treated as being that stable. 
They've been becoming more stable, but they've been a work in progress and as 
such have been breaking code. As we shift to to them being stable, 
deprecations will then be rarer and more reasonable to keep around. It'll also 
be far more reasonable to expect code older than a release or three to 
continue to compile with new releases, which has definitely not been the case 
with a lot of the library changes that were made in the past (most of which 
have been completed - the std.string stuff is some of the last stuff still 
around). I honestly don't expect code compiled with 2.051 to continue to work 
in general. Too much has changed since then, much of which was done in an 
attempt to clean up Phobos prior to committing to having a stable API that we 
expect to continue to work for years to come. We've been giving people who 
maintain their code ample notice and ample time to fix their code as we've 
progressed, but we haven't been operating with the idea that old code would 
compile 9 releases later. Rather, we've been trying to clean stuff up so that 
we could operate that way without having to maintain bad code forever (or to 
at least minimize that). We do need to start operating with the idea that code 
will compile 9+ releases later, but stuff like the std.string deprecations were 
not done with the idea that they would stay around long term.

So, I see stuff like the std.string deprecations as being fundamentally 
different from deprecations that will happen in the future. We're moving from a 
model where we were trying to clean up the standard library in order to 
stabilize it to one where it's stable and shouldn't be changing that much 
aside from additions. And I think that it's perfectly reasonable to treat 
deprecations differently in those two situations. So, I'm definitely going to 
push for removing stuff that's already been deprecated. It's already broken 
people's code by being deprecated due to how deprecated currently works, so 
it's really not going to cost anyone much for them to be outright removed now. 
And in the case of the std.string deprecations, they'll even get nice messages 
asking them things like if they really meant toLower instead of tolower.

I don't like leaving clutter in code, and in this case, I think that it's safe 
and reasonable to clean up that clutter.

- Jonathan M Davis
December 03, 2012
Re: Deprecated Library Functions / Methods
On Sunday, 2 December 2012 at 23:56:29 UTC, Jonathan M Davis 
wrote:
[... <breath> snip </breath> ...]

> I don't like leaving clutter in code, and in this case, I think 
> that it's safe
> and reasonable to clean up that clutter.
>
> - Jonathan M Davis

+1
December 03, 2012
Re: Deprecated Library Functions / Methods
To resolve this kind of no-win argument, you have to solve the 
root problem.

You cannot use an unstable version of D as a stable version, for 
obvious reasons, each new stable release of D "stable" appears to 
be a new unstable release of D.

It won't work to simply lock down D into only a stable version. 
Doing that will piss off a lot of people who want to see new 
breaking improvements implemented and released for use, and not 5 
years later either, but a lot sooner.

Here's a simple example of a possible real solution for Phobos, 
for sake of discussion I'm assuming DMD will be released under a 
major.minor.revision numbering system, with stable and unstable 
branches.

1) Assign Phobos it's own independent major.minor.revision number 
with the major number locked in with the corresponding compatible 
major DMD number. That way, users will know what Phobos version 
is compatible with what DMD version.

2) Include multiple backwards compatible versions of Phobos with 
each DMD release stored in a way that allows versions of Phobos 
to be selectable by the D programmer.

I know that there are plenty of challenges to overcome wrt 
changing the way D is being developed and released, but to try 
and develop D using only one version for both stable and unstable 
is simply not going to work. It also will not work to lock down D 
and prevent it from improving in breaking ways overthe next 5 
years (or whatever).

--rt
December 03, 2012
Re: Deprecated Library Functions / Methods
On Monday, 3 December 2012 at 00:52:55 UTC, Joshua Niehus wrote:
>> I don't like leaving clutter in code, and in this case, I 
>> think that it's safe and reasonable to clean up that clutter.
>>
>> - Jonathan M Davis
> +1


-1. There's really no harm in leaving it there. On my hard drive, 
I have somewhere in the ballpark of a gigabyte of code saved 
(includes random apps I've compiled over the years).

I don't know what most of it is, and I don't really care. If I 
need it, its there, and if not, whatever, there's not much, if 
anything, of a downside to having crap saved. My hard drive is 
still 75% free, access to the files I want is as fast as ever, 
and so on.

With deprecated alias.... if you don't use it, whatever. With old 
code, if you don't use it.... you won't even notice its there.

The only real downside I can think of is making the full download 
a bit slower. I don't think this is important. zipped code is 
small code. Besides, with the real world "problem" today, what 
are we even talking about? 50 kilobytes? Big deal.
December 03, 2012
Re: Deprecated Library Functions / Methods
On Monday, December 03, 2012 02:49:39 Rob T wrote:
> I know that there are plenty of challenges to overcome wrt
> changing the way D is being developed and released, but to try
> and develop D using only one version for both stable and unstable
> is simply not going to work. It also will not work to lock down D
> and prevent it from improving in breaking ways overthe next 5
> years (or whatever).

There is still a considerable difference between a library which is intended to 
be stable and one which is under heavy development. We've essentially been 
working under a model where the API was fluid enough that we could break code 
as long as we gave enough warning first. We want to move to a model where the 
API is stable enough that code written now will compile 5+ years from now with 
no changes. We can still look at phasing out stuff that needs to be replaced. 
It's just that we then need to keep it around (even if it's deprecated and 
undocumented), whereas when the API is under heavier development, more 
permanent breakage has been permissible. For instance, std.date is dead and 
gone, having been replaced by std.datetime, and that was a good decision at 
the time given the level of stability of the library. But if we were to 
replace std.xml with std.xml2 now, we would need to keep std.xml around long 
term (even if it's deprecated and undocumented) so that code would continue to 
compile for years to come, because we've reached a point when we want to have 
a stable API that people can rely on rather than trying to clean up all of the 
little things that we were trying to clean up before.

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.

- Jonathan M Davis
December 03, 2012
Re: Deprecated Library Functions / Methods
On Monday, December 03, 2012 02:58:57 Adam D. Ruppe wrote:
> On Monday, 3 December 2012 at 00:52:55 UTC, Joshua Niehus wrote:
> >> I don't like leaving clutter in code, and in this case, I
> >> think that it's safe and reasonable to clean up that clutter.
> >> 
> >> - Jonathan M Davis
> > 
> > +1
> 
> -1. There's really no harm in leaving it there. On my hard drive,
> I have somewhere in the ballpark of a gigabyte of code saved
> (includes random apps I've compiled over the years).
> 
> I don't know what most of it is, and I don't really care. If I
> need it, its there, and if not, whatever, there's not much, if
> anything, of a downside to having crap saved. My hard drive is
> still 75% free, access to the files I want is as fast as ever,
> and so on.
> 
> With deprecated alias.... if you don't use it, whatever. With old
> code, if you don't use it.... you won't even notice its there.
> 
> The only real downside I can think of is making the full download
> a bit slower. I don't think this is important. zipped code is
> small code. Besides, with the real world "problem" today, what
> are we even talking about? 50 kilobytes? Big deal.

It's messy and ugly to leave dead code around in a library. It also makes it 
so that it's possible for people to keep writing code which uses it when they 
shouldn't be.

I'm all for moving to a model where we keep deprecated stuff around for stuff 
that we deprecate in the future, but I'm completely against leaving the stuff 
that we currently have deprecated around. It was changed in an effort to clean 
up the library in preparation for having a clean, stable API, and leaving it 
around is messy and counter to that purpose.

- Jonathan M Davis
December 03, 2012
Re: Deprecated Library Functions / Methods
On 12/3/2012 1:03 PM, Jonathan M Davis wrote:
> It's messy and ugly to leave dead code around in a library. It also makes it
> so that it's possible for people to keep writing code which uses it when they
> shouldn't be.

It is not dead code, there are people using it.

As for aesthetics, it can be moved to the end of the module, and 
visually segregated.

Also, if the documentation for it is removed, I seriously doubt that 
sensible people will use it in new code.


> I'm all for moving to a model where we keep deprecated stuff around for stuff
> that we deprecate in the future, but I'm completely against leaving the stuff
> that we currently have deprecated around. It was changed in an effort to clean
> up the library in preparation for having a clean, stable API, and leaving it
> around is messy and counter to that purpose.

Breaking peoples' existing, working, stable code is worse than offending 
a notion of clutter, especially because only phobos developers will even 
see that clutter.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home