On Thursday, 23 May 2013 at 05:32:13 UTC, deadalnix wrote:
> On Thursday, 23 May 2013 at 03:15:44 UTC, Jonathan M Davis wrote:
>> Every time that a library change is introduced it's done in a way that allows
>> the programmer time to migrate their code. I'm not aware of any case thus far
>> where we've purposefully changed library code in a manner which immediately
>> broke user code. We don't even do that with the compiler. The problem is all
>> of the times that it happens on accident (particularly with compiler
>> regressions). So, regardless, we're not going to immediately break code out
>> from under people.
>>
>
> Inconsistent naming is the #1 complaint about PHP. After using D for years, I still don't know what some modules are about in phobos.
>
> Yeah, it is worth it.

+1

On 2013-05-23 05:15, Jonathan M Davis wrote:

> Every time that a library change is introduced it's done in a way that allows
> the programmer time to migrate their code. I'm not aware of any case thus far
> where we've purposefully changed library code in a manner which immediately
> broke user code. We don't even do that with the compiler. The problem is all
> of the times that it happens on accident (particularly with compiler
> regressions). So, regardless, we're not going to immediately break code out
> from under people.

Surprise, surprise. This just happened for me today. There were static methods in DWT marked as "shared". This doesn't compile with the latest beta (2.063 5). No warnings, no deprecation message, just suddenly stopped compiling.

> So, the question is whether it's worth making people change their code
> sometime between when we make the change and when std.uni finally goes away.
> And I don't think that making people change their code is worth it regardless
> of how gradual it is. std.uni is not as good a name as std.unicode, but it's
> just not worth forcing people to change their code in order to fix it. If we
> keep trying to tweak the names of modules and functions and whatnot, we'll
> never be in a state where people can rely on their code compiling across
> compiler versions. Tweaking some stuff is necessary, and we did a lot in the
> past to fix symbol names, but we've pretty much stopped doing that, and we have
> to draw the line somewhere.

How about drawing the line after we have gone through and cleaned up all modules that haven't gone through the review queue.

-- 
/Jacob Carlborg

On Tuesday, 21 May 2013 at 14:58:56 UTC, Peter Alexander wrote:
> On Tuesday, 21 May 2013 at 14:32:46 UTC, Domain wrote:
>> I vote for std.unicode. Actually, I thought it was std.uri at the first glance. And I never thought uni is short for unicode.
>
> +1
>
> I wondered what uni meant the first time I read it as well. I didn't know until I looked at the docs. I've never seen Unicode shortened to uni in my life.

http://docs.oracle.com/cd/B19306_01/server.102/b14200/functions204.htm

On Thursday, May 23, 2013 09:15:22 Jacob Carlborg wrote:
> > So, the question is whether it's worth making people change their code sometime between when we make the change and when std.uni finally goes away. And I don't think that making people change their code is worth it regardless of how gradual it is. std.uni is not as good a name as std.unicode, but it's just not worth forcing people to change their code in order to fix it. If we keep trying to tweak the names of modules and functions and whatnot, we'll never be in a state where people can rely on their code compiling across compiler versions. Tweaking some stuff is necessary, and we did a lot in the past to fix symbol names, but we've pretty much stopped doing that, and we have to draw the line somewhere.
> 
> How about drawing the line after we have gone through and cleaned up all modules that haven't gone through the review queue.

Even if we agreed that we wanted to do that, how is that realistically going to happen? Pretty much the only reason that as many of Phobos' names have been fixed as have been is because I took the time a couple of years ago to clean up a lot of the names so that they followed the naming conventions. Some changes were done by others, but the vast majority of it was me. If I hadn't taken the time to do that, it wouldn't have happened. And in all that time, no one else has taken the time to try and figure out what I missed and get that fixed. At best, some folks have fixed a few symbol names here and there. It's just not realistic to expect that we're going to be able to go through and fix every little naming detail in Phobos at this point. And as time passes, the cost of making the changes goes up, because the amount of code written using the old names increases. There was plenty of screaming about names being changed when I did it before. It would likely be even worse now, and the longer it took to actually find and fix every naming convention violation in Phobos, the more code which would be written using the old names and would break when we made the changes.

I tried to fix all of the naming problems in Phobos previously with the idea that we'd fix them all and then move on, and I got a large portion of them fixed, but I didn't get them all, and I think that it's past the time when it's reasonable to do so. There are too many people pushing for stability, and the lack of perceived stability is one of D's biggest detractors right now (regardless of what our actual level of stability is). Walter and Andrei in particular are of the opinion that the ROI on name changes at this point is too low for it to be worth it. Sure, aesthetically, it would be nice to fix them all, but at some point, we have to just move on and live with what we have. Fortunately, _most_ of it has been fixed already, and the biggest remaining offenders are modules that should probably be replaced wholesale anyway (e.g. std.socket), so they may get fixed if the ROI for replacing such modules is high enough (in which case, the fixing of names is a bonus which comes along with fixing something which actually _does_ have a ROI for changing it).

I understand why people want changes like this (and to some extent, I agree), but I think that if they really wanted them, they should have pushed for them and created pull requests for them long before now.

- Jonathan M Davis

On 2013-05-23 10:49, Jonathan M Davis wrote:

> I understand why people want changes like this (and to some extent, I agree),
> but I think that if they really wanted them, they should have pushed for them
> and created pull requests for them long before now.

I don't see how a pull request will help. The problem is that none of the developers that have push/merge permissions want to change the names. Would you merge a pull request that changed "dur" to "duration" in std.datetime?

-- 
/Jacob Carlborg

On Thursday, May 23, 2013 11:10:04 Jacob Carlborg wrote:
> On 2013-05-23 10:49, Jonathan M Davis wrote:
> > I understand why people want changes like this (and to some extent, I agree), but I think that if they really wanted them, they should have pushed for them and created pull requests for them long before now.
> 
> I don't see how a pull request will help. The problem is that none of the developers that have push/merge permissions want to change the names.

We did it before for quite a few functions, but Andrei and Walter are very much against it now. Merging changes like that at this point would likely incur their wrath. But we've had years where they could have been fixed, and 90+% of the changes were done by me. Other people made some name changes as well, and they got merged, but very few people who were pushing for name changes ever went and actually submitted pull requests for them. Previously, they would have been merged, but not now.

> Would you merge a pull request that changed "dur" to "duration" in std.datetime?

Definitely not. But I wouldn't have changed that even if Walter and Andrei thought that we should go through the entirety of Phobos and clean up all of the names no matter how much code broke. While dur is not a great name, duration is too long when coupled with the template arguments (which is why it got shortened in the first place). I was between a rock and a hard place on that one, and I decided that it was more useable in this case to go with the shorter name, even if it wasn't ideal. Clearly, you don't agree, but we now have minutes, seconds, etc. as aliases if you don't like dur.

If Andrei and Walter weren't so against making name changes at this point, I probably would merge pull requests with name fixes that I agreed with (I certainly would have a year or two ago), but increasingly, I agree with them that we need to stop doing that. It's just taken too long to sort that out, and we need to work on making sure that the compiler and standard library are stable more than we need to sort out some aesthetic fixes for APIs and the like, as nice as it would be to have those fixes. And no, we're not completely stable yet, but unless we try to restrict breaking changes to places with a high ROI, we never will be stable.

- Jonathan M Davis

On 2013-05-23 12:21, Jonathan M Davis wrote:
> Clearly, you don't agree, but we now
> have minutes, seconds, etc. as aliases if you don't like dur.

Yeah, that's better.

-- 
/Jacob Carlborg

On Thursday, 23 May 2013 at 08:46:02 UTC, Kagamin wrote:
> On Tuesday, 21 May 2013 at 14:58:56 UTC, Peter Alexander wrote:
>> On Tuesday, 21 May 2013 at 14:32:46 UTC, Domain wrote:
> http://docs.oracle.com/cd/B19306_01/server.102/b14200/functions204.htm

Sorry, but is a bit misleading. Yes, UNISTR, since you expect a STRing, will almost automatically make you think about UNIcode (since there are only so many possibilities).

But in a more general context, "UNI" is not as expressive.

Am Tue, 21 May 2013 20:34:02 +0200
schrieb Jacob Carlborg <doob@me.com>:

> On 2013-05-21 19:53, Idan Arye wrote:
> 
> > The problem is that people that need Unicode stuff see `std.utf` and assume that all Unicode related stuff are there.
> 
> I never can remember if I should look in std.utf or std.uni. That wouldn't change if it was renamed to std.unicode.

...and looking at the content I really wonder what the distinction is. I wouldn't say that "Unicode" is much more than "Utf". All in all it is another way (or several ways) to assign numbers to characters. Before this long discussion I thought "std.encoding.unicode", "std.encoding.ascii", etc. makes sense and I still think so. It also makes it more likely that authors of such modules try to keep a common layout or set of functions for everything in std.encoding. Just my 2¢ ;)

-- 
Marco

Am Tue, 21 May 2013 19:12:12 +0200
schrieb Jacob Carlborg <doob@me.com>:

> On 2013-05-21 14:51, Dmitry Olshansky wrote:
> > The pitch by deadalnix:
> >
> > I strongly push into renaming it to std.unicode . As said in the other thread : uni can be unicode, but also unique, union, unit, uniform, unix, unijambist, whatever.
> 
> How about std.encoding.unicode to get a proper hierarchy into phobos.

+1