View mode: basic / threaded / horizontal-split · Log in · Help
July 12, 2011
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
On 7/11/2011 8:31 AM, Andrej Mitrovic wrote:
> Walter, could you please add these to the changelog:

Done.
July 13, 2011
Re: dmd 1.069 and 2.054 release
Thanks!
July 13, 2011
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
> 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
Re: dmd 1.069 and 2.054 release
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
3 4 5 6 7 8
Top | Discussion index | About this forum | D home