Just for fun, I've decided to try and get MicroEmacs in D added to the dub registry. The last time it compiled was 2 years ago.

I wound up with at least a dozen references to Phobos names that have disappeared. No corrective action was indicated, just "undefined symbol". I have to go refigure out what the code was trying to do, and go poking through the Phobos documentation to see what will work today.

I know there's been a lot of "break my code" advocacy lately, but this code was only 2 years old.

I fully understand how unfriendly this is to users and how discouraging it can be to have their recently working code shattered and scattered. We need to do a lot better.

On Fri, 28 Nov 2014 15:33:51 -0800
Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Just for fun, I've decided to try and get MicroEmacs in D added to the dub registry. The last time it compiled was 2 years ago.
> 
> I wound up with at least a dozen references to Phobos names that have disappeared. No corrective action was indicated, just "undefined symbol". I have to go refigure out what the code was trying to do, and go poking through the Phobos documentation to see what will work today.
> 
> I know there's been a lot of "break my code" advocacy lately, but this code was only 2 years old.
> 
> I fully understand how unfriendly this is to users and how discouraging it can be to have their recently working code shattered and scattered. We need to do a lot better.
like, for example, having some tool that will analyze the old code and autofix it/suggest replacement.

oh, wait... such tool was suggested years ago and has no signs of "official blessing" until this year's summer! and now it can't fix two-year-old code.

On 11/28/14, 5:39 PM, ketmar via Digitalmars-d wrote:
> oh, wait... such tool was suggested years ago and has no signs of
> "official blessing" until this year's summer! and now it can't fix
> two-year-old code.

I don't understand this attitude.  Don't wait for any sort of gold star rubber stamp ticker tape parade.  If you think something is worth doing, do it.

"Walter Bright"  wrote in message news:m5b0p2$1bv4$1@digitalmars.com...

> Just for fun, I've decided to try and get MicroEmacs in D added to the dub registry. The last time it compiled was 2 years ago.
>
> I wound up with at least a dozen references to Phobos names that have disappeared. No corrective action was indicated, just "undefined symbol". I have to go refigure out what the code was trying to do, and go poking through the Phobos documentation to see what will work today.
>
> I know there's been a lot of "break my code" advocacy lately, but this code was only 2 years old.
>
> I fully understand how unfriendly this is to users and how discouraging it can be to have their recently working code shattered and scattered. We need to do a lot better.

Two years is too old, you skipped all the deprecation stages. 

Walter Bright:

> We need to do a lot better.

I agree. D has to come back to the living. It looks like D is hibernating.

Bye,
bearophile

On Fri, Nov 28, 2014 at 03:33:51PM -0800, Walter Bright via Digitalmars-d wrote:
> Just for fun, I've decided to try and get MicroEmacs in D added to the dub registry. The last time it compiled was 2 years ago.
> 
> I wound up with at least a dozen references to Phobos names that have disappeared. No corrective action was indicated, just "undefined symbol". I have to go refigure out what the code was trying to do, and go poking through the Phobos documentation to see what will work today.
> 
> I know there's been a lot of "break my code" advocacy lately, but this code was only 2 years old.
> 
> I fully understand how unfriendly this is to users and how discouraging it can be to have their recently working code shattered and scattered. We need to do a lot better.

I think we may have been a little trigger-happy in implementing the deprecation cycle. While technically the deprecation cycle lasts 2 years (?), I think it's probably a good idea to keep deprecated symbols around for far longer than that. You never know when somebody decides to dust off some 5-y.o. code that references an obscure Phobos symbol that has since been deleted after a full deprecation cycle.

Perhaps what we need is, after a symbol has passed the deprecation cycle, replace its original definition with a static assert(0). Something like this:

	// Original implementation:
	/**
	 * Original docs
	 */
	auto mySymbol(A...)(A args) { /* original implementation */ }

	// Some time later we decide to deprecate it. Before marking it
	// deprecated, label it with a big fat warning:
	/**
	 * Original docs
	 *
	 * Warning: This function is slated for deprecation by May 2015.
	 */
	auto mySymbol(A...)(A args) { /* original implementation */ }

	// Afterwards, the deprecated tag is added (ddocs are removed so
	// that new users will stop using it).
	deprecated("Please use myOtherSymbol instead.")
	auto mySymbol(A...)(A args) { /* original implementation */ }

	// Full deprecation cycle passes. Using this symbol should now
	// be an error, even if -d is being used. But don't delete it
	// just yet:
	deprecated("Please use myOtherSymbol instead.")
	auto mySymbol(A...)(A args) {
		static assert(0, "Please use myOtherSymbol instead.");
	}

	// After a REALLY long time, I dunno, maybe 4 years? 5 years?
	// We can finally remove it.

This does mean, though, that once released, symbols will stick around for a LONG time, which means some overloads cannot be used if it conflicts with a deprecated symbol, etc.. So std.experimental becomes even more important, to sort out APIs before they essentially get frozen in stone and need >=5 years of proverbial laser scrubbing before they can be erased again.

There's also the issue of symbols being moved into a different module -- existing code will expect to find it in the old place, so any aliases / public imports / etc., will have to stay around for quite a long time before they can be gotten rid of. Ditto for currently monolithic modules that eventually gets split into saner-sized chunks.


T

-- 
Acid falls with the rain; with love comes the pain.

On Fri, 28 Nov 2014 17:43:16 -0600
Brad Roberts via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 11/28/14, 5:39 PM, ketmar via Digitalmars-d wrote:
> > oh, wait... such tool was suggested years ago and has no signs of "official blessing" until this year's summer! and now it can't fix two-year-old code.
> 
> I don't understand this attitude.  Don't wait for any sort of gold star rubber stamp ticker tape parade.  If you think something is worth doing, do it.
writing and *supporting* such tool (linter, fixer) which is inevitably tied to the compiler and stdlib development process is a hard work. the author of the tool wants to be sure that this tool is "blessed", so he can interop with other teams. users of such tool wants to be sure that this is not the "one man work" which can disappear any time when author becomes bored.

actually, such tool is a part of the compiler suite. that's why it's very little motivation to do it without "blessing". someone can write some quickhack tool for himself to fix *his* codebase, but making such tool usable for others, documenting it and so on is a great amount of work.

see, i have the tool that fixes my dmd code for gdc. it successfully processes all my code, 'cause i know my coding habits and can do this with simple regexps. can this tool be used by someone else, on very different codebase? i doubt it. can it be fixed to process other codebases? i doubt it, it doesn't even have the proper parser. do i motivated to improve it? not at all. "blessing" is a motivation.

like, say, D->C++ translator which i suggested in the thread about bootstraping D compiler which is written in D. the answer was "no, it's unlikely to be accepted". do i want to spend alot of my time on the code that i myself don't need at all, and without any hope that it will be used later? nope. i have alot of things to code that are interesting for me.

"blessing" for companion tools is a motivator.

On 11/28/2014 3:46 PM, Daniel Murphy wrote:
> Two years is too old, you skipped all the deprecation stages.

My favorite unhelpful message:

  src/med/spawn.d(62): Error: undefined identifier sleep, did you mean template slurp(Types...)(string filename, in char[] format)?

Grepping around revealed that sleep() had migrated to core.sys.posix.unistd

On Sat, Nov 29, 2014 at 10:46:14AM +1100, Daniel Murphy via Digitalmars-d wrote:
> "Walter Bright"  wrote in message news:m5b0p2$1bv4$1@digitalmars.com...
> 
> >Just for fun, I've decided to try and get MicroEmacs in D added to the dub registry. The last time it compiled was 2 years ago.
> >
> >I wound up with at least a dozen references to Phobos names that have disappeared. No corrective action was indicated, just "undefined symbol".  I have to go refigure out what the code was trying to do, and go poking through the Phobos documentation to see what will work today.
> >
> >I know there's been a lot of "break my code" advocacy lately, but this code was only 2 years old.
> >
> >I fully understand how unfriendly this is to users and how discouraging it can be to have their recently working code shattered and scattered. We need to do a lot better.
> 
> Two years is too old, you skipped all the deprecation stages.

>From an end user's POV, though, two years does seem like a short time. I
mean, I have C/C++ projects dating from 20 years ago, and you wouldn't believe it, but almost all of them compile with no change on a modern compiler. Granted, the comparison isn't altogether fair, since D is changing a lot faster than C/C++, but still, 2 years is quite short from that POV. Not everybody is constantly trying to compile code with git HEAD and fixing compiling errors on every personal pet project they have, that, on the off-chance, might stop compiling after 2 years.

Perhaps it's time to reconsider the length of the deprecation cycle, from an end user's POV, rather than from the POV of the D devs who can't wait to junk the old stuff and move on to the new.

Alternatively, we should have a "compatibility mode" for the compiler / Phobos, where certain parts of the code are version'd out as they get deprecated, but you can get them back by using an appropriate version declaration:

	// Some phobos module
	version(PhobosCompat_2066)
	{
		// Old version - compile with version=PhobosCompat_2066
		// to get this symbol back
		auto oldSymbol(...) { ... }
	}
	else
	{
		// New version
		deprecated("Please use newSymbol instead.")
		auto oldSymbol(...) { ... }
	}

This works reasonably well for Phobos, but I don't know how to do this in the compiler without ending up with an ugly plate of unmaintainable spaghetti.


T

-- 
In theory, there is no difference between theory and practice.

On 11/28/2014 3:53 PM, H. S. Teoh via Digitalmars-d wrote:
> I think we may have been a little trigger-happy in implementing the
> deprecation cycle. While technically the deprecation cycle lasts 2 years
> (?), I think it's probably a good idea to keep deprecated symbols around
> for far longer than that. You never know when somebody decides to dust
> off some 5-y.o. code that references an obscure Phobos symbol that has
> since been deleted after a full deprecation cycle.

And, when they are removed for good, there needs to be section in the phobos module documentation that gives a list of gone names and corresponding new names. If the hapless coder greps for "fnmatch", there are no hits in Phobos.

I don't so much mind the name change as I mind not knowing "how do I fix it?". Even if I find a new name, such as "fnmatch" seems to have been replaced with "globMatch", I'm not so sure it has the same behavior.

In not one of the cases of changed Phobos names was corrective action presented. (The spell checker suggested replacement names, but was always wrong.)

In most of the cases where the language changed, the compiler produced correct corrective action advice.