July 12, 2011
Michel Fortin, el 12 de julio a las 18:03 me escribiste:
> On 2011-07-12 16:52:10 -0400, Leandro Lucarella <luca@llucax.com.ar> said:
> >This is what deprecated is for! Removing stuff breaks code, not deprecating stuff! Deprecated really is "scheduled for removal", so "scheduled for deprecation" is "scheduled for scheduled for removal", it makes no sense. Fix the compiler!
> 
> Actually it sometime makes sense that you'd schedule something to be later scheduled for removal. If there is no replacement for a certain feature, making it deprecated is just a nuisance since the compiler will complain about the problem but you have no alternative yet.

What's the point of scheduling something for removal when you don't have an alternative? I really can't see the point. If you just plan to do an alternative but you don't want to bother anyone, just don't mark it as deprecated. If you do want to tell people "hey, better not to use this", then mark it as deprecated. If you have a replacement you can't even schedule anything, and if you can, you can deprecate it too.

> Now, I think the argument for scheduling things for deprecation is just an extreme of that: deprecating things is a nuisance because it breaks code, so we'll schedule them to be deprecated later. But then we add a warning for those things scheduled for deprecation because we don't want people to use them, and "scheduled for deprecation" has just become a synonym for "deprecated but not yet breaking your code". Fixing deprecated to not break code by default is a better option, I think.

Agreed, changing the default in my patch is a one-line change.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
hypocrite opportunist
don't infect me with your poison
July 12, 2011
Jonathan M Davis, el 12 de julio a las 21:51 me escribiste:
> If you want how the language treats deprecated to change, then feel free to create a pull request and try and talk Walter into it. Arguably, warning about deprecation and then only failing to compile when the deprecated stuff is actually removed is the better way to handle things. But that's not how D is designed (probably at least in part because Walter doesn't really believe in warnings). So, feel free to try and talk Walter into it, but unless the default behavior is changed, deprecating something is going to silently break people's code unless you tell them about it first (which is the point of scheduling something for deprecation).

So, your solution is issuing warnings behind the compiler and Walter's back. Great! I love this! Now I remember why I loved D so much =P

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
El amor es como una reina ortopédica.
	-- Poroto
July 12, 2011
Jonathan M Davis wrote:
> The current plan is that _everything_ which gets deprecated will be removed.

What's the reason for removing things? Surely it's not disk space!


Anyway, let's look at the three categories. While I hate change, there are two kinds of change: trivial and painful. Remember, D isn't a useless piece of junk dynamic language - trivial changes are easy to find and easy to change with confidence.

Painful changes though, are, well, painful.


> 1. Renaming stuff to follow Phobos' naming conventions.

These are trivial, just change it. It's like ripping off a band-aid. The compiler will tell you what broke and how to fix it (the spell checker ought to catch camelcase changes without keeping the old name).

Do it fast, feel the brief pain, and move on.


> 2. Small redesigns of older functionality.

These should be reasonably trivial fixes too, but might warrant deprecating the old on a case by case basis. If it's mindless to change though, just rip that bandage off.

Just make sure that the types are different or something, while still super easy to change, so the compiler will point it out to you.


> 3. Full module redesigns due to the need of serious improvement

This is where the pain comes in, since instead of spending 15 minutes running a mindless find/replace when the compiler tells you to, it requires gutting a lot of code and rethinking it, converting databases, etc.

These should ideally aim to redesign the internals, but keep the same interface. Maybe adding to it or writing the old as an emulation layer over the new.

This is preferred, since then new and old exist together. It avoids actually breaking anybody's code.


If that's impossible though, this is the most likely candidate for deprecation. Unlike a name change, it isn't easy to change, so a compile error is more likely to mean reverting dmd versions than actually changing it.
July 13, 2011
On 7/11/2011 8:31 AM, Andrej Mitrovic wrote:
> Walter, could you please add these to the changelog:

Done.
July 13, 2011
Thanks!
July 13, 2011
On Tuesday 12 July 2011 23:38:10 Adam D. Ruppe wrote:
> Jonathan M Davis wrote:
> > The current plan is that _everything_ which gets deprecated will be removed.
> 
> What's the reason for removing things? Surely it's not disk space!
> 
> 
> Anyway, let's look at the three categories. While I hate change, there are two kinds of change: trivial and painful. Remember, D isn't a useless piece of junk dynamic language - trivial changes are easy to find and easy to change with confidence.
> 
> Painful changes though, are, well, painful.
> 
> > 1. Renaming stuff to follow Phobos' naming conventions.
> 
> These are trivial, just change it. It's like ripping off a band-aid. The compiler will tell you what broke and how to fix it (the spell checker ought to catch camelcase changes without keeping the old name).
> 
> Do it fast, feel the brief pain, and move on.

Hmm. I don't think that Walter would be very happy about that, since it does immediately break code, but as long as the name change is easily found by the spellchecker, it wouldn't be a big deal to fix. So, under at least some circumstances, that may be acceptable. Regardless, it could be grounds for making the deprecation cycle for renaming relatively short instead of around 1 year as is the current plan for deprecation in general.

> > 2. Small redesigns of older functionality.
> 
> These should be reasonably trivial fixes too, but might warrant deprecating the old on a case by case basis. If it's mindless to change though, just rip that bandage off.
> 
> Just make sure that the types are different or something, while still super easy to change, so the compiler will point it out to you.
> 
> > 3. Full module redesigns due to the need of serious improvement
> 
> This is where the pain comes in, since instead of spending 15 minutes running a mindless find/replace when the compiler tells you to, it requires gutting a lot of code and rethinking it, converting databases, etc.
> 
> These should ideally aim to redesign the internals, but keep the same interface. Maybe adding to it or writing the old as an emulation layer over the new.
> 
> This is preferred, since then new and old exist together. It avoids actually breaking anybody's code.
> 
> 
> If that's impossible though, this is the most likely candidate for deprecation. Unlike a name change, it isn't easy to change, so a compile error is more likely to mean reverting dmd versions than actually changing it.

At this point, I expect that the module rewrites are going to generally be full-on, completely incompatible rewrites. Fixing the API is one of the major reasons for the rewrites (particularly when converting a module  to being range-based as is going to occur with std.stream), so just changing the implementation isn't going to cut it. It may be that in some cases, it's essentially a rewrite of a broken implementation, but I'm not aware of any such case at the moment. These are definitely cases, however, where the full deprecation cycle is going to be used, so there should be plenty of time to fix code. Hopefully, these changes get done fairly soon, but some of them don't seem to be going anywhere yet in spite of major discussions about them (e.g. std.stream). They're also the most work to do, so while I would expect most of the #1 and #2 types of deprecations to occur fairly soon for the most part, the full module rewrites could take a while, which is unfortunate.

Off the top of my head, I know that std.xml, std.stream, std.path, and std.json are going to get rewrites on some level, and std.container could get some major rewrites depending on what Andrei does with memory management in it, though what it needs primarily is new containers. Also, Andrei thinks that std.encoding is a failed experiment which needs to be redone, so that's probably going to need to be rewritten at some point. And as I understand it, all of those except for std.stream and std.encoding have someone actively working on them (though maybe Andrei has been working on std.stream too; I don't know). So, hopefully it won't be too much longer before they're done, but it could also be a while unfortunately.

So, anyway, there are some module rewrites to be done, and they're likely to be pretty major for better or worse. But once those are done, with the review process vetting new modules, deprecation issues like these should be far rarer, and Phobos should be heading towards stability.

- Jonathan M Davis
July 13, 2011
On Tuesday 12 July 2011 19:18:10 Leandro Lucarella wrote:
> Jonathan M Davis, el 12 de julio a las 21:51 me escribiste:
> > If you want how the language treats deprecated to change, then feel free to create a pull request and try and talk Walter into it. Arguably, warning about deprecation and then only failing to compile when the deprecated stuff is actually removed is the better way to handle things. But that's not how D is designed (probably at least in part because Walter doesn't really believe in warnings). So, feel free to try and talk Walter into it, but unless the default behavior is changed, deprecating something is going to silently break people's code unless you tell them about it first (which is the point of scheduling something for deprecation).
> 
> So, your solution is issuing warnings behind the compiler and Walter's back. Great! I love this! Now I remember why I loved D so much =P

Nothing is being done behind anyone's back. It was Walter who pushed for stuff to be scheduled for deprecation before being actually deprecated, because he didn't want code breaking on people without any warning. We decided to use pragmas to present messages to the user informing them of the impending deprecation, because the language doesn't currently have anything built in with the concept of "scheduled for deprecation." It was either that or not warn about the impending deprecation except in the changelog and documentation, in which case, anyone who doesn't pay enough attention to those would still end up with their code being broken without warning when the symbols are actually deprecated. So, we went for the messages. If the majority of people would prefer not to have the messages and risk having their code break when something is deprecated, because they missed the notice in the changelog or documentation, then the messages will go away. But we thought that they were a good idea, so we put them in there. None of this is trying to circumvent Walter or the compiler.

- Jonathan M Davis
July 13, 2011
On 12.07.2011 17:07, Trass3r wrote:
>>> Now I have to use an ugly hack to achieve something as simple as
>>> toUpper:
>>>
>>> mixin( (){char[] tmp = "...".dup; toUpperInPlace(tmp); return tmp;}() );
>>
>> Damn i found that too and wanted to mention it in the dmd-beta list b4
>> release. But the workaround is simple. At least this one was fixed:
>>
>> http://lists.puremagic.com/pipermail/dmd-beta/2011-July/000773.html
>>
>> Cause that was making cl4d with all its string mixins pretty much
>> unbuildable at all.
>
> Yeah I've done some crazy shit in the cl4d code :D
> But in the end that was just another workaround cause template mixins
> couldn't mixin constructors.
> Good news: this seems to have been fixed.
> Bad news: there still is another problem. I asked about it in D.learn.
>
>
> btw, that problem you reported, where did it occur in cl4d?


It occured for the mixin method to generate the different exception classes. Specifically the toCamelCase method was not working there.
July 13, 2011
> It occured for the mixin method to generate the different exception classes. Specifically the toCamelCase method was not working there.

Ok.

Do you have any idea how to solve the problem I described in D.learn? ("template instance cannot use local.....")
July 13, 2011
Looks like it fails to build under Linux using linux.mak makefile due to missing
intrange.c / intrange.o in file lists. Linking stage errors. When I add them
manually, everything works like a charm.
Could this one be fixed?
Best Regards,
Mihail