View mode: basic / threaded / horizontal-split · Log in · Help
November 30, 2012
Re: Deprecated Library Functions / Methods
11/30/2012 9:27 PM, Chris пишет:
> There have been quite a few changes since 2.051 and I cannot stick to
> that version, because I would introduce more deprecated code. I wanted
> to update my code but saw in the library that again loads of methods
> were scheduled for deprecation. So what's the point?
>

Java has plenty deprecated stuff. So does *cough* php. So do other 
languages. That alone is not an indication of anything except of the 
on-going development. There are always references to (usually) better 
replacements.

There are still cases of simple renaming  to make functions follow the 
convention, but these ones are easily fixed with find/replace.

> Changes are necessary and I think they are reasonable (like the regex
> algorithm), but as a developer who uses D, you need some sort of
> security, i.e. that your code won't break in a few months' time. I
> really appreciate the fantastic work on D, but sometimes it seems to me
> like a "code laboratory" where programmers test certain ideas,
> algorithms, approaches etc, which would be fine for a college project.
> But if you have to use and work with the library to develop real world
> applications, it's a nightmare.

I'd just keep certain version of the compiler & phobos + libs that are 
needed. And then when deadlines are passed do some refactoring/tweaking 
to bump used versions up a notch. I agree that it's far from ideal.

> If this doesn't change, I fear D will
> never take off. Most frameworks at least "tolerate" deprecated functions
> until developers have time to update their code.
>

The deprecated APIs do still work if you use the -d switch. What is far 
more shattering are compiler changes (and bugfixes, sadly) given that 
2.051 is 9 versions behind he latest it won't surprise me that it breaks 
a _lot_.

> Most frameworks at least "tolerate" deprecated functions
> until developers have time to update their code.

Problem is these frameworks also have certain version requirement last 
time I checked it goes like this: requires  php 5.3+ or say python 2.5+ 
 etc.

So we'd better have certain D versions that are more lasting. But 
that'll make sense once the feature set is fully implemented and polished.

Anyway see D stable topic.

-- 
Dmitry Olshansky
November 30, 2012
Re: Deprecated Library Functions / Methods
Great to hear that. I'd like to see D take off one day.
November 30, 2012
Re: Deprecated Library Functions / Methods
Am Fri, 30 Nov 2012 10:19:08 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> On 11/30/12 10:04 AM, Chris wrote:
> > Is there a way of telling when things in the library will calm down
> > and it'll be save to develop in D and update old code?
> 
> Thanks for this testimony.
> 
> Andrei

I think what we need is a "hard cut" for phobos.
We could release 2.061 and then stop all regular bug fixing /
enhancement work on phobos for two weeks. In those two weeks all work
would be concentrated on reviewing the existing phobos modules. So we'd
start a wiki page, assign every module to at least one person reviewing
it. Those people should correct naming and codig style of the module in
their local repositories. Controversial changes could be discussed on
the wiki. If names have to be changed to match the coding conventions
the old names should be deprecated.

Some modules should be deprecated as a whole, even if we do not yet
have a proper replacement yet. For example we know for many years that
std.xml is broken and nobody is fixing it, but we still ship it with
phobos. std.signal is written in an old D1 style. std.json should
probably be removed as well. We should get rid of all that legacy even
if we don't have a replacement yet.

In the end we would have a 2.062 release with all the old functionality
(deprecated) and new functionality / names matching our coding
conventions. Some releases later (e.g. 2.064) all deprecated
functionality will be removed. Then everyone knows that:

* The new functions in 2.062 should be used ASAP. 
* 2.063 will be the last version supporting the deprecated
 functionality.
* 2.064 will be 'clean'. All deprecated features will be removed and
 the rest of the functions will be stable. (At very least there will
 be no more naming changes or similar stuff)

So we'd end up with a phobos with less functionality because of the
dropped features and upgrading user code to 2.064 might be a bigger
task, but we will guarantee that there will be no (or at least very few)
breaking changes after 2.064 and obeying the naming conventions in all
modules should lead to a better user experience.


If someone really needs a deprecated module like std.xml it could
always be maintained in a different repository / project but we should
remove everything from phobos which doesn't fit our quality standards.
November 30, 2012
Re: Deprecated Library Functions / Methods
On Friday, November 30, 2012 16:04:01 Chris wrote:
> Is there a way of telling when things in the library will calm
> down and it'll be save to develop in D and update old code?
> 
> I started with D2 version 2.051 and created a medium-sized
> project fairly quickly, but now I have a lot of deprecated
> methods in my code. I couldn't keep up with all the changes and I
> have been hesitant to update my code because there are still a
> lot of "Will be removed in September/November/December ..."
> warnings in the library. Much that I like D, I simply cannot
> develop in D at the moment due to the constant changes in the
> Phobos library. I have this sinking feeling that this is killing
> the language.

A lot of changes were being done for a while to try and rename stuff to the 
follow the correct naming scheme and make other needed adjustments. That has 
dropped off considerably however and the goal is to make deprecations rare. 
It's just that there were a lot of changes that needed to be made to clean up 
the library. Most of that has been done has been done now, and the remainder 
is likely to just not be cleaned up or to stick around long term with an 
alternative which has been cleaned up. We don't want a lot of churn in the 
standard library. We want it to be stable so that people can rely on their 
code continuing to compile.

At present, there should be very little which is currently scheduled for 
deprecation, and it's unknown how long the stuff which has been actually 
deprecated will stay around. We were removing after 6 months of deprecation 
but have been re-examining that.

What we're trying to get Walter to do is to make it so that deprecated just 
generates warnings, not errors (rather a new flag will be added to make them 
generate errors if that's what you want, and -d will stay the same). With 
that, anything that gets deprecated should stick around for quite a while 
(though there's a good chance that it'll end up being undocumented after a 
while in order to further discourage its use), and it won't actually prevent 
compilation, just bug you to update your code. But as deprecations should 
become much rarer, even that won't happen anywhere near as often. There's an 
open pull request to make the change, but Walter hasn't agreed to it yet:

https://github.com/D-Programming-Language/dmd/pull/1287

I'd very much like to see the large blocks of stuff that was renamed or moved 
fully removed rather than sticking around as deprecated (e.g. std.ctype and 
all of the deprecated functions in std.string should go away), but we do want 
to be moving away from making large breaking changes like that, and 
deprecations should become quite rare. Pretty much all of those kind of 
changes which have been suggested recently have been rejected.

- Jonathan m Davis
December 01, 2012
Re: Deprecated Library Functions / Methods
On 2012-11-30 20:11, Johannes Pfau wrote:

> In the end we would have a 2.062 release with all the old functionality
> (deprecated) and new functionality / names matching our coding
> conventions. Some releases later (e.g. 2.064) all deprecated
> functionality will be removed. Then everyone knows that:

Don't we usually keep deprecated features for 6 months or so?

-- 
/Jacob Carlborg
December 01, 2012
Re: Deprecated Library Functions / Methods
On Friday, 30 November 2012 at 15:04:02 UTC, Chris wrote:
> Is there a way of telling when things in the library will calm 
> down and it'll be save to develop in D and update old code?
>
> I started with D2 version 2.051 and created a medium-sized 
> project fairly quickly, but now I have a lot of deprecated 
> methods in my code. I couldn't keep up with all the changes and 
> I have been hesitant to update my code because there are still 
> a lot of "Will be removed in September/November/December ..." 
> warnings in the library. Much that I like D, I simply cannot 
> develop in D at the moment due to the constant changes in the 
> Phobos library. I have this sinking feeling that this is 
> killing the language.

Why not make a branch of D then use the patch as the source for 
your compilation. When new changes occur you can try them out. If 
they break your source then try and update your branch with only 
things that do not break your source.

No one is forcing you to use a newer version of D. The only 
purpose is for stability and enhancements. Not all stability 
patches and enhancements will break your code(many with be 
orthogonal).

Obviously the drawback is managing the branch, but if it's such a 
big issue it can be done.
December 01, 2012
Re: Deprecated Library Functions / Methods
>
> Some modules should be deprecated as a whole, even if we do not 
> yet
> have a proper replacement yet. For example we know for many 
> years that
> std.xml is broken and nobody is fixing it, but we still ship it 
> with

Shouldn't the new version be called std.xml2 while leaving the 
old std.xml in phobos? Basically no replacement.
December 01, 2012
Re: Deprecated Library Functions / Methods
>
> You can either stay at a given version of D. Or you could use 
> something more stable than Phobos. Tango, for example, is very

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.
December 02, 2012
Re: Deprecated Library Functions / Methods
On Sunday, December 02, 2012 00:40:20 sclytrack wrote:
> > Some modules should be deprecated as a whole, even if we do not
> > yet
> > have a proper replacement yet. For example we know for many
> > years that
> > std.xml is broken and nobody is fixing it, but we still ship it
> > with
> 
> Shouldn't the new version be called std.xml2 while leaving the
> old std.xml in phobos? Basically no replacement.

We've talked about doing that with modules that we intend to replace where it 
doesn't make sense to give them a new name - std.xml being one of them - but 
nothing like that has happened yet. The closest would be std.regexp -> 
std.regex and std.date -> std.datetime, and both of those obviously involved 
renaming. But I would expect std.xml to be replaced with std.xml2 at some 
point.

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.

- Jonathan M Davis
December 02, 2012
Re: Deprecated Library Functions / Methods
Am Sat, 01 Dec 2012 16:52:19 -0800
schrieb Jonathan M Davis <jmdavisProg@gmx.com>:

> > 
> > Shouldn't the new version be called std.xml2 while leaving the
> > old std.xml in phobos? Basically no replacement.
> 
> We've talked about doing that with modules that we intend to replace
> where it doesn't make sense to give them a new name - std.xml being
> one of them - but nothing like that has happened yet. The closest
> would be std.regexp -> std.regex and std.date -> std.datetime, and
> both of those obviously involved renaming. But I would expect std.xml
> to be replaced with std.xml2 at some point.
> 
> 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.
> 
> - Jonathan M Davis

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.

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.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home