Re: std.uni vs std.unicode and beyond?
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
Re: std.uni vs std.unicode and beyond?
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
Re: std.uni vs std.unicode and beyond?
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
Re: std.uni vs std.unicode and beyond?
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
Re: std.uni vs std.unicode and beyond?
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
Re: std.uni vs std.unicode and beyond?
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
Re: std.uni vs std.unicode and beyond?
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.
Re: std.uni vs std.unicode and beyond?
Am Tue, 21 May 2013 20:34:02 +0200 schrieb Jacob Carlborg d...@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
Re: std.uni vs std.unicode and beyond?
Am Tue, 21 May 2013 19:12:12 +0200 schrieb Jacob Carlborg d...@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
Re: std.uni vs std.unicode and beyond?
On Friday, 24 May 2013 at 03:19:48 UTC, Marco Leise wrote: Am Tue, 21 May 2013 20:34:02 +0200 schrieb Jacob Carlborg d...@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¢ ;) To make it precise, unicode is a association between characters and numbers. An encoding is how theses number actually are stored in a file. Typical encoding for unicode are utf-8/16/32
Re: std.uni vs std.unicode and beyond?
On Thursday, 23 May 2013 at 08:49:15 UTC, Jonathan M Davis wrote: 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 though more about this. I do think the ROI is very real, but the one that gain the benefit are the one that aren't used to the module. Which mean that the one that will pay for the change won't be the one benefiting from it. I do think that we have a lot of people to come in the future, and so that the change is worth it. Obviously, who's paying is an issue, and I'd rather work on making that smooth for who's paying than discarding the change altogether.
Re: std.uni vs std.unicode and beyond?
On Tue, 21 May 2013 13:01:57 -0400, nazriel s...@dzfl.pl wrote: On Tuesday, 21 May 2013 at 16:52:06 UTC, Steven Schveighoffer wrote: Deprecated functions don't compile. Any code that uses it would have to be modified. They do. Unless you add compiler switch they will compile and only spit out an warning. So you are right. That was recently changed in 2.061, I didn't realize that. -Steve
Re: std.uni vs std.unicode and beyond?
On Tuesday, 21 May 2013 at 16:52:06 UTC, Steven Schveighoffer wrote: On Tue, 21 May 2013 12:43:01 -0400, Regan Heath re...@netmail.co.nz wrote: On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer schvei...@yahoo.com wrote: It has nothing to do with the name. I think unicode is better. But (allegedly) we have existing projects that use std.uni, which would break if we renamed. Wouldn't the old std.uni remain but deprecated? Deprecated functions don't compile. Any code that uses it would have to be modified. Only non-breaking solution would be to keep both. In the past, it has been suggested to have std.uni simply publicly import std.unicode (or analogous solution to some other module renaming). You would always retain std.uni in this solution. -Steve When `std.regexp` was deprecated, they used a pragma for the deprecation message: https://github.com/D-Programming-Language/phobos/blob/2.062/std/regexp.d#L127L128 The same thing could be done for `std.uni`. If there is a big plan to restructure Phobos then `std.uni` can be deprecated now, and be removed completely once the big backward compatibility break is done. If there is no such plan, the removal of `std.uni` will cause too much redundant breakage in no-longer-maintained libraries.
Re: std.uni vs std.unicode and beyond?
On Tue, 21 May 2013 13:08:46 -0400, Regan Heath re...@netmail.co.nz wrote: On Tue, 21 May 2013 17:52:10 +0100, Steven Schveighoffer schvei...@yahoo.com wrote: On Tue, 21 May 2013 12:43:01 -0400, Regan Heath re...@netmail.co.nz wrote: On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer schvei...@yahoo.com wrote: It has nothing to do with the name. I think unicode is better. But (allegedly) we have existing projects that use std.uni, which would break if we renamed. Wouldn't the old std.uni remain but deprecated? Deprecated functions don't compile. Any code that uses it would have to be modified. dmd -d Apparently, they DO compile with only a warning now. This is better than before. relying on dmd -d is a bad idea, since it's too blunt (ALL deprecated features in existence are now enabled without warnings). Only non-breaking solution would be to keep both. In the past, it has been suggested to have std.uni simply publicly import std.unicode (or analogous solution to some other module renaming). You would always retain std.uni in this solution. Ick no. With the advent that deprecated features are now warnings instead of errors, it might be doable, and just remove std.uni after a year or so. What we need to establish what the cost is to projects that use std.uni currently. I have no idea, since I don't use it. Then we can correctly judge whether the name change is worth doing. I don't know that it is. std.uni is not immediately recognizable as something else, so it warrants a lookup in the docs. Yes, less obvious, but not horrifically misnamed. I don't think it's worth the effort to rename at this point unless it's shown that nearly nobody uses it. -Steve
Re: std.uni vs std.unicode and beyond?
On Tue, 21 May 2013 13:21:36 -0400, Idan Arye generic...@gmail.com wrote: When `std.regexp` was deprecated, they used a pragma for the deprecation message: https://github.com/D-Programming-Language/phobos/blob/2.062/std/regexp.d#L127L128 The same thing could be done for `std.uni`. These past events have already been identified as mistakes by Walter and company. I don't think we should follow that tack either. -Steve
Re: std.uni vs std.unicode and beyond?
On 5/21/13 1:27 PM, Steven Schveighoffer wrote: Then we can correctly judge whether the name change is worth doing. I don't know that it is. std.uni is not immediately recognizable as something else, so it warrants a lookup in the docs. Yes, less obvious, but not horrifically misnamed. I don't think it's worth the effort to rename at this point unless it's shown that nearly nobody uses it. I agree. I'd personally love it if std.unicode replaced std.uni, but at this point the rename is insufficiently motivated. It's not like people go, hmmm I need some Unicode stuff, let me see if std.unicode is there. No? The hell with it, I'm moving to another language. Andrei
Re: std.uni vs std.unicode and beyond?
On Tuesday, 21 May 2013 at 17:12:14 UTC, Jacob Carlborg wrote: 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
Re: std.uni vs std.unicode and beyond?
On Tuesday, 21 May 2013 at 17:31:59 UTC, Andrei Alexandrescu wrote: On 5/21/13 1:27 PM, Steven Schveighoffer wrote: Then we can correctly judge whether the name change is worth doing. I don't know that it is. std.uni is not immediately recognizable as something else, so it warrants a lookup in the docs. Yes, less obvious, but not horrifically misnamed. I don't think it's worth the effort to rename at this point unless it's shown that nearly nobody uses it. I agree. I'd personally love it if std.unicode replaced std.uni, but at this point the rename is insufficiently motivated. It's not like people go, hmmm I need some Unicode stuff, let me see if std.unicode is there. No? The hell with it, I'm moving to another language. Andrei The problem is that people that need Unicode stuff see `std.utf` and assume that all Unicode related stuff are there.
Re: std.uni vs std.unicode and beyond?
On 5/21/13 1:53 PM, 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 understand. Well, std.utf's documentation can always cross-reference into std.unicode etc. Basically what I'm saying is that nowadays searching and cross-referencing is fairly commoditized so we needn't worry about people being unable to find things that are there. Andrei
Re: std.uni vs std.unicode and beyond?
On 2013-05-21, 16:02, Regan Heath wrote: On Tue, 21 May 2013 14:20:50 +0100, Dmitry Olshansky dmitry.o...@gmail.com wrote: 21-May-2013 17:03, Regan Heath пишет: [snip] [snip] [snip] Meaning if we can make an incremental change for the better For better how? The endless churn in my opinion is not worth the incremental change for better. You also would have to argue for every single change with folks pushing whichever way they feel like to (not talking about uni). This is a proverbial design by committee. Another generalisation. No-one is suggesting we start renaming modules just because user X wants to. All I suggested is that if we get a chance to do so at the same time as another breaking change to the same module, we should - provided the benefit of the rename is clear. I believe his point was rather that this time around we get std.unicode. Next module is std.encoding.ascii, and then comes std.text.ebcdic. I'm all for calling it *.unicode instead of *.uni - that part is only logical. However, there should be a roadmap as to whether * should be std, std.encoding, or whatever. -- Simen
Re: std.uni vs std.unicode and beyond?
On Tuesday, 21 May 2013 at 17:53:02 UTC, 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 see (and experience myself) a lot of confusion over this. Dealing with strings a person constantly has to guess which of these modules has what they are looking for: std.algorithm std.ascii std.conv std.encoding std.range std.string std.format std.uni std.utf It's a mess. At least grouping the encoding stuff together would give it some structure.
Re: std.uni vs std.unicode and beyond?
On Tue, 21 May 2013 14:23:24 -0400, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: module std.uni; public import std.unicode; alias std.unicode.foo foo; alias std.unicode.bar bar; pragma(msg, Please import std.unicode instead of std.uni) EOF from here: http://dlang.org/module.html#ImportDeclaration All symbols from a publicly imported module are also aliased in the importing module. This means that if module D imports module C, and module C publicly imports module B which has the symbol bar, in module D you can access the symbol via bar, B.bar, and C.bar. -Steve
Re: std.uni vs std.unicode and beyond?
std.algo std.uni // Ok or std.algorithm std.unicode // OK or std.algorithm std.uni -- WTF? - newbie
Re: std.uni vs std.unicode and beyond?
On Tue, 21 May 2013 14:33:48 -0400 Steven Schveighoffer schvei...@yahoo.com wrote: On Tue, 21 May 2013 14:23:24 -0400, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: module std.uni; public import std.unicode; alias std.unicode.foo foo; alias std.unicode.bar bar; pragma(msg, Please import std.unicode instead of std.uni) EOF from here: http://dlang.org/module.html#ImportDeclaration All symbols from a publicly imported module are also aliased in the importing module. This means that if module D imports module C, and module C publicly imports module B which has the symbol bar, in module D you can access the symbol via bar, B.bar, and C.bar. Nice. Is that a new thing, or have I managed to overlook it for years?
Re: std.uni vs std.unicode and beyond?
On Tue, 21 May 2013 14:54:42 -0400, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Tue, 21 May 2013 14:33:48 -0400 Steven Schveighoffer schvei...@yahoo.com wrote: All symbols from a publicly imported module are also aliased in the importing module. This means that if module D imports module C, and module C publicly imports module B which has the symbol bar, in module D you can access the symbol via bar, B.bar, and C.bar. Nice. Is that a new thing, or have I managed to overlook it for years? Like I did? Yes :) I think I became aware about a couple years ago in one of those periodic discussions on how to migrate the current flat hierarchy to a nested one. -Steve
Re: std.uni vs std.unicode and beyond?
On Tuesday, 21 May 2013 at 18:23:42 UTC, Dmitry Olshansky wrote: 21-May-2013 22:12, Brad Anderson пишет: On Tuesday, 21 May 2013 at 17:53:02 UTC, Idan Arye wrote: I see people have no idea what Unicode is about. Unicode is not only the encoding - it's a de facto standard of internationalization and related algorithms. UTF is encoding. Good point, but this fact only supports the assertion that the current state of phobos is even more messy than expected. So, a bit of cleaning is required. Since we are at it, ascii is both a standard *and* an encoding (well, the only one), so were should be put? in std.encoding.* or in std.standard.*? maybe std.text.ascii? std.text.unicode? std.text.utf?
Re: std.uni vs std.unicode and beyond?
On Tuesday, 21 May 2013 at 18:23:42 UTC, Dmitry Olshansky wrote: 21-May-2013 22:12, Brad Anderson пишет: On Tuesday, 21 May 2013 at 17:53:02 UTC, 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 see (and experience myself) a lot of confusion over this. Dealing with strings a person constantly has to guess which of these modules has what they are looking for: std.algorithm std.ascii std.conv std.encoding std.range std.string std.format std.uni std.utf It's a mess. At least grouping the encoding stuff together would give it some structure. I see people have no idea what Unicode is about. Unicode is not only the encoding - it's a de facto standard of internationalization and related algorithms. UTF is encoding. If I see a module called utf and I don't see a module called unicode, I automatically assume that utf contains Unicode related stuff as well. And visa versa - if I see unicode and not utf, I assume unicode contains the UTF stuff. Sure, they are not the same - but they are related enough that people will expect them to share a module.
Re: std.uni vs std.unicode and beyond?
On Tuesday, May 21, 2013 16:51:01 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. When theses pile up in a large library, this is more and more difficult to rely on intuition/autocompletion and much more on programmer's memory. It mean that it takes longer to learn the whole library. My reservations: If the chief benefit of renaming is aesthetics then I'd rather pass. This kind of knee-jerk changes made on basis of a good time to try to push a better name just don't belong in design of library/package structure. Yeah, I know nobody is going to say package structure looking at Phobos. If we make it a part of restructuring std.* that is long overdue then I'm fine as long as package structure is well thought out as a whole. Changing it now before adopting a package structure risks the 2nd change and another set of arguments for keeping things as is. Let's continue discussion here and not in voting thread. I'm completely against renaming it. It will break code for little benefit. And given that std.uni is actually one of the modules that you're _likely_ to have to give the full path to (in particular because std.ascii has many of the same functions but for ASCII), making it longer would be annoying. Maybe std.unicode would be okay if we were creating a brand new module, but std.uni already exists. Let's just leave it as-is. - Jonathan M Davis
Re: std.uni vs std.unicode and beyond?
On Tuesday, 21 May 2013 at 18:23:42 UTC, Dmitry Olshansky wrote: I see people have no idea what Unicode is about. Unicode is not only the encoding - it's a de facto standard of internationalization and related algorithms. UTF is encoding. Point taken. Nevertheless, it's all still all rather confusing (and I even know the difference between encodings and unicode and I still conflated them).
Re: std.uni vs std.unicode and beyond?
On Tuesday, 21 May 2013 at 19:40:03 UTC, eles wrote: On Tuesday, 21 May 2013 at 18:23:42 UTC, Dmitry Olshansky wrote: 21-May-2013 22:12, Brad Anderson пишет: On Tuesday, 21 May 2013 at 17:53:02 UTC, Idan Arye wrote: I see people have no idea what Unicode is about. Unicode is not only the encoding - it's a de facto standard of internationalization and related algorithms. UTF is encoding. Good point, but this fact only supports the assertion that the current state of phobos is even more messy than expected. So, a bit of cleaning is required. Since we are at it, ascii is both a standard *and* an encoding (well, the only one), so were should be put? in std.encoding.* or in std.standard.*? maybe std.text.ascii? std.text.unicode? std.text.utf? `std.standard` is a bad name for a package. Sure, ASCII is a standard, but the fact that it is a standard has nothing to do with what the `*.ascii` module does - you won't find a function in `std.ascii` that sends an email to the committee with an improvement suggestion for the next edition. Ofcourse, one can only claim that the only reason such function does not exist is that the ASCII standard would probably never see another update... On the other hand, all the functions in `std.ascii` have something much do with the fact that ASCII is an encoding, so `std.encoding.ascii` is a good name. Same with `*.unicode` - even though it has a better chance than the ASCII version, you see a function to mail a suggestion there either. And yes, it's an algorithm - but almost everything is an algorithm! Unicode and ASCII, even if you can argue they are not exactly and only encodings, are *about* encoding - and that's why they fit in `std.encoding.*`.
Re: std.uni vs std.unicode and beyond?
On Tuesday, 21 May 2013 at 20:12:37 UTC, Jonathan M Davis wrote: I'm completely against renaming it. It will break code for little benefit. And given that std.uni is actually one of the modules that you're _likely_ to have to give the full path to (in particular because std.ascii has many of the same functions but for ASCII), making it longer would be annoying. Maybe std.unicode would be okay if we were creating a brand new module, but std.uni already exists. Let's just leave it as-is. - Jonathan M Davis Would the public import people are suggesting not work for maintaining backward compatibility? Also, couldn't you just do import uni = std.unicode to save on typing in modules that make use of both std.ascii and std.unicode (that's even less typing than the current requirement to type the fully qualified name which includes std)?
Re: std.uni vs std.unicode and beyond?
On Tuesday, 21 May 2013 at 17:31:59 UTC, Andrei Alexandrescu wrote: On 5/21/13 1:27 PM, Steven Schveighoffer wrote: Then we can correctly judge whether the name change is worth doing. I don't know that it is. std.uni is not immediately recognizable as something else, so it warrants a lookup in the docs. Yes, less obvious, but not horrifically misnamed. I don't think it's worth the effort to rename at this point unless it's shown that nearly nobody uses it. I agree. I'd personally love it if std.unicode replaced std.uni, but at this point the rename is insufficiently motivated. It's not like people go, hmmm I need some Unicode stuff, let me see if std.unicode is there. No? The hell with it, I'm moving to another language. Andrei It isn't really a rename as a new module is being integrated. We can keep what we have under std.uni for a while. If you want the new hotness, go for std.unicode .
Re: std.uni vs std.unicode and beyond?
On 05/21/2013 12:56 PM, Andrei Alexandrescu wrote: On 5/21/13 1:53 PM, 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 understand. Well, std.utf's documentation can always cross-reference into std.unicode etc. Basically what I'm saying is that nowadays searching and cross-referencing is fairly commoditized so we needn't worry about people being unable to find things that are there. Andrei What about a tool, similar to 2to3.py or whatever it's called? It would be nice to start heading in that direction in either case. I can see minor things like this potentially being fixed automatically, and with a nice warning to let you know to stop doing it. signature.asc Description: OpenPGP digital signature
Re: std.uni vs std.unicode and beyond?
On Tue, 21 May 2013 19:04:25 +0100, Simen Kjaeraas simen.kja...@gmail.com wrote: On 2013-05-21, 16:02, Regan Heath wrote: On Tue, 21 May 2013 14:20:50 +0100, Dmitry Olshansky dmitry.o...@gmail.com wrote: 21-May-2013 17:03, Regan Heath пишет: [snip] [snip] [snip] Meaning if we can make an incremental change for the better For better how? The endless churn in my opinion is not worth the incremental change for better. You also would have to argue for every single change with folks pushing whichever way they feel like to (not talking about uni). This is a proverbial design by committee. Another generalisation. No-one is suggesting we start renaming modules just because user X wants to. All I suggested is that if we get a chance to do so at the same time as another breaking change to the same module, we should - provided the benefit of the rename is clear. I believe his point was rather that this time around we get std.unicode. Next module is std.encoding.ascii, and then comes std.text.ebcdic. I'm all for calling it *.unicode instead of *.uni - that part is only logical. However, there should be a roadmap as to whether * should be std, std.encoding, or whatever. Agreed, we need a goal/structure to work towards. Given that we can make simple/single changes toward that goal/direction as/when possible. It's like renovating a house, you do it room by room and never change the colour scheme/design half way through - or you'd have to go back and re-do the first rooms. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: std.uni vs std.unicode and beyond?
On Tue, 21 May 2013 19:23:36 +0100, Dmitry Olshansky dmitry.o...@gmail.com wrote: 21-May-2013 22:12, Brad Anderson пишет: On Tuesday, 21 May 2013 at 17:53:02 UTC, 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 see (and experience myself) a lot of confusion over this. Dealing with strings a person constantly has to guess which of these modules has what they are looking for: std.algorithm std.ascii std.conv std.encoding std.range std.string std.format std.uni std.utf It's a mess. At least grouping the encoding stuff together would give it some structure. I see people have no idea what Unicode is about. Unicode is not only the encoding - it's a de facto standard of internationalization and related algorithms. UTF is encoding. So.. surely this suggests some structure would help with that, i.e. std.encoding.ascii std.encoding.latin1 std.encoding.utf std.i18n.unicode R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: std.uni vs std.unicode and beyond?
21-May-2013 22:12, Brad Anderson пишет: On Tuesday, 21 May 2013 at 17:53:02 UTC, 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 see (and experience myself) a lot of confusion over this. Dealing with strings a person constantly has to guess which of these modules has what they are looking for: std.algorithm std.ascii std.conv std.encoding std.range std.string std.format std.uni std.utf It's a mess. At least grouping the encoding stuff together would give it some structure. I see people have no idea what Unicode is about. Unicode is not only the encoding - it's a de facto standard of internationalization and related algorithms. UTF is encoding. -- Dmitry Olshansky
Re: std.uni vs std.unicode and beyond?
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. -- /Jacob Carlborg
Re: std.uni vs std.unicode and beyond?
On 05/21/2013 12:56 PM, Andrei Alexandrescu wrote: On 5/21/13 1:53 PM, 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 understand. Well, std.utf's documentation can always cross-reference into std.unicode etc. Basically what I'm saying is that nowadays searching and cross-referencing is fairly commoditized so we needn't worry about people being unable to find things that are there. Andrei Lol, I see the talk about it on the talk now. signature.asc Description: OpenPGP digital signature
Re: std.uni vs std.unicode and beyond?
On Tue, 21 May 2013 16:51:01 +0400 Dmitry Olshansky dmitry.o...@gmail.com 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. Or a British University. :) FWIW, I prefer std.unicode, and I have absolutely no personal objections to having to change my code to match. And heck, it's easy enough to ease transition with: module std.uni; public import std.unicode; alias std.unicode.foo foo; alias std.unicode.bar bar; pragma(msg, Please import std.unicode instead of std.uni) EOF But that said, if people say we don't need no steeenkin' module renaming!, I'm perfectly fine with that, too. tl;dr: My preference is std.unicode, but I don't really care.
Re: std.uni vs std.unicode and beyond?
On Tuesday, May 21, 2013 22:32:00 Brad Anderson wrote: Would the public import people are suggesting not work for maintaining backward compatibility? Also, couldn't you just do import uni = std.unicode to save on typing in modules that make use of both std.ascii and std.unicode (that's even less typing than the current requirement to type the fully qualified name which includes std)? Of course we can provide a migration path, but you're still talking about breaking code, and I don't think that std.uni is a bad enough name to merit that. If we were starting from scratch or didn't care about breaking code, then I think that std.unicode would make good sense. std.uni is nice and short, but it's overly short. However, we're _not_ starting from scratch and we do care about breaking code - and we're caring about that more and more. So, I don't think that renaming it at this point would be appropriate. - Jonathan M Davis
Re: std.uni vs std.unicode and beyond?
On Tuesday, May 21, 2013 23:25:47 deadalnix wrote: It isn't really a rename as a new module is being integrated. We can keep what we have under std.uni for a while. If you want the new hotness, go for std.unicode . Except that std.uni already exists. It's just that we're adding a bunch more to it and improving the implementation of what's already there. Changing the name _will_break code, and as the benefits of renaming it are purely aesthetic, I don't think that it's worth it. - Jonathan M Davis
Re: std.uni vs std.unicode and beyond?
On Tuesday, May 21, 2013 23:25:47 deadalnix wrote: It isn't really a rename as a new module is being integrated. We can keep what we have under std.uni for a while. If you want the new hotness, go for std.unicode . Except that std.uni already exists. It's just that we're adding a bunch more to it and improving the implementation of what's already there. Changing the name _will_break code, and as the benefits of renaming it are purely aesthetic, I don't think that it's worth it. - Jonathan M Davis
Re: std.uni vs std.unicode and beyond?
On 2013-05-21, 22:12, Jonathan M Davis wrote: given that std.uni is actually one of the modules that you're _likely_ to have to give the full path to Uhm, you *do* know D has renamed imports, right? import uni = std.unicode; // Look ma, even shorter than std.uni! -- Simen
Re: std.uni vs std.unicode and beyond?
On Wednesday, 22 May 2013 at 17:31:17 UTC, Jonathan M Davis wrote: Of course we can provide a migration path, but you're still talking about breaking code, and I don't think that std.uni is a bad enough name to merit that. More specifically, what I'm wondering is whether or not it's considered a breaking change if your code still compiles and works exactly as it did before except for perhaps a deprecation warning during the build? I could be misunderstanding what the proposed public import solution would accomplish but it sounded like std.uni could be upgraded with Dmitry's improvements while getting a new module name that is easier for newcomers to find. It sounded like win-win to me.
Re: std.uni vs std.unicode and beyond?
On Wednesday, May 22, 2013 22:07:24 Brad Anderson wrote: On Wednesday, 22 May 2013 at 17:31:17 UTC, Jonathan M Davis wrote: Of course we can provide a migration path, but you're still talking about breaking code, and I don't think that std.uni is a bad enough name to merit that. More specifically, what I'm wondering is whether or not it's considered a breaking change if your code still compiles and works exactly as it did before except for perhaps a deprecation warning during the build? I could be misunderstanding what the proposed public import solution would accomplish but it sounded like std.uni could be upgraded with Dmitry's improvements while getting a new module name that is easier for newcomers to find. It sounded like win-win to me. Code wouldn't break immediately, but everyone would have to change their code eventually if we're deprecating std.uni in favor of std.unicode. So, we'd be forcing everyone to change their code purely for aesthetics, and we've almost entirely stopped doing that at this point. Walter and Andrei in particular are very much against renaming things at this point. The ROI on the change is too small. - Jonathan M Davis
Re: std.uni vs std.unicode and beyond?
On Wednesday, 22 May 2013 at 17:31:17 UTC, Jonathan M Davis wrote: On Tuesday, May 21, 2013 22:32:00 Brad Anderson wrote: Would the public import people are suggesting not work for maintaining backward compatibility? Also, couldn't you just do import uni = std.unicode to save on typing in modules that make use of both std.ascii and std.unicode (that's even less typing than the current requirement to type the fully qualified name which includes std)? Of course we can provide a migration path, but you're still talking about breaking code, and I don't think that std.uni is a bad enough name to merit that. I don't understand why do we need to break code here. It is about introducing a new module.
Re: std.uni vs std.unicode and beyond?
On Thursday, 23 May 2013 at 00:43:04 UTC, deadalnix wrote: On Wednesday, 22 May 2013 at 17:31:17 UTC, Jonathan M Davis wrote: On Tuesday, May 21, 2013 22:32:00 Brad Anderson wrote: Would the public import people are suggesting not work for maintaining backward compatibility? Also, couldn't you just do import uni = std.unicode to save on typing in modules that make use of both std.ascii and std.unicode (that's even less typing than the current requirement to type the fully qualified name which includes std)? Of course we can provide a migration path, but you're still talking about breaking code, and I don't think that std.uni is a bad enough name to merit that. I don't understand why do we need to break code here. It is about introducing a new module. Doing it while keeping `std.uni` would create a duplication in both API and implementation, since `std.unicode` will contain all the functionality of `std.uni`. Eventually `std.uni` would have to be removed, because if Phobos would keep the old versions forever whenever a better version that does the same thing comes it will become very cluttered. Java walked that way. Once the old `std.uni` will be finally removed - code will break.
Re: std.uni vs std.unicode and beyond?
On Thursday, 23 May 2013 at 01:24:42 UTC, Idan Arye wrote: Doing it while keeping `std.uni` would create a duplication in both API and implementation, since `std.unicode` will contain all the functionality of `std.uni`. Eventually `std.uni` would have to be removed, because if Phobos would keep the old versions forever whenever a better version that does the same thing comes it will become very cluttered. Java walked that way. Once the old `std.uni` will be finally removed - code will break. Yes, that is exactly what is needed. Today we only consider not breaking at all, or breaking it as of next version of DMD and without any support for what come before the breakage. This boolean choice mindset isn't helping.
Re: std.uni vs std.unicode and beyond?
On Thursday, May 23, 2013 03:42:56 deadalnix wrote: On Thursday, 23 May 2013 at 01:24:42 UTC, Idan Arye wrote: Doing it while keeping `std.uni` would create a duplication in both API and implementation, since `std.unicode` will contain all the functionality of `std.uni`. Eventually `std.uni` would have to be removed, because if Phobos would keep the old versions forever whenever a better version that does the same thing comes it will become very cluttered. Java walked that way. Once the old `std.uni` will be finally removed - code will break. Yes, that is exactly what is needed. Today we only consider not breaking at all, or breaking it as of next version of DMD and without any support for what come before the breakage. This boolean choice mindset isn't helping. 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. 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. The general push has been to stabilize our the compiler and Phobos, and tweaking names does not help with that and generally has a low ROI. - Jonathan M Davis
Re: std.uni vs std.unicode and beyond?
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.
Re: std.uni vs std.unicode and beyond?
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
Re: std.uni vs std.unicode and beyond?
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. When theses pile up in a large library, this is more and more difficult to rely on intuition/autocompletion and much more on programmer's memory. It mean that it takes longer to learn the whole library. My reservations: If the chief benefit of renaming is aesthetics then I'd rather pass. This kind of knee-jerk changes made on basis of a good time to try to push a better name just don't belong in design of library/package structure. Yeah, I know nobody is going to say package structure looking at Phobos. If we make it a part of restructuring std.* that is long overdue then I'm fine as long as package structure is well thought out as a whole. Changing it now before adopting a package structure risks the 2nd change and another set of arguments for keeping things as is. Let's continue discussion here and not in voting thread. I vote for changing to std.unicode. We need to stop using these ridiculous shortenings that gain nothing. Just because C shortens everything doesn't mean D should. -- /Jacob Carlborg
Re: std.uni vs std.unicode and beyond?
On Tue, 21 May 2013 13:51:01 +0100, Dmitry Olshansky dmitry.o...@gmail.com 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. When theses pile up in a large library, this is more and more difficult to rely on intuition/autocompletion and much more on programmer's memory. It mean that it takes longer to learn the whole library. My reservations: If the chief benefit of renaming is aesthetics then I'd rather pass. It's not aesthetics. It's to make it clear what the module is/does. I read std.uni again recently, after being away from D for a while and briefly wondered what uni stood for, I loaded the docs and it was clear .. but that initial doubt was still there. Had it been called std.unicode I would have known without looking. This kind of knee-jerk changes made on basis of a good time to try to push a better name just don't belong in design of library/package structure. Yeah, I know nobody is going to say package structure looking at Phobos. True. If we make it a part of restructuring std.* that is long overdue then I'm fine as long as package structure is well thought out as a whole. Good structure can come about from a complete top down design.. but also from many small changes towards a better whole. This is perhaps one such change? Changing it now before adopting a package structure risks the 2nd change and another set of arguments for keeping things as is. Are we ever going to have a complete restructuring? I doubt it.. Meaning if we can make an incremental change for the better now when there is some obviation of the resulting issues then we should, or we risk more resistance in the future. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: std.uni vs std.unicode and beyond?
21-May-2013 17:03, Regan Heath пишет: [snip] My reservations: If the chief benefit of renaming is aesthetics then I'd rather pass. It's not aesthetics. It's to make it clear what the module is/does. I read std.uni again recently, after being away from D for a while and briefly wondered what uni stood for, I loaded the docs and it was clear .. but that initial doubt was still there. Had it been called std.unicode I would have known without looking. This kind of knee-jerk changes made on basis of a good time to try to push a better name just don't belong in design of library/package structure. Yeah, I know nobody is going to say package structure looking at Phobos. True. If we make it a part of restructuring std.* that is long overdue then I'm fine as long as package structure is well thought out as a whole. Good structure can come about from a complete top down design.. but also from many small changes towards a better whole. This is perhaps one such change? Without direction to follow there could be no end of such changes nor grief for the user and maintenance burden for maintainers. Changing it now before adopting a package structure risks the 2nd change and another set of arguments for keeping things as is. Are we ever going to have a complete restructuring? I doubt it.. Why not - Phobos is going to grow way beyond what it's now. There has been thread on which structure to adopt but it didn't went far. Meaning if we can make an incremental change for the better For better how? The endless churn in my opinion is not worth the incremental change for better. You also would have to argue for every single change with folks pushing whichever way they feel like to (not talking about uni). This is a proverbial design by committee. now when there is some obviation of the resulting issues then we should, or we risk more resistance in the future. Any change will leave a deprecated module that references it's new true location. Thus the less steps we do the less is damage done in the long run. -- Dmitry Olshansky
Re: std.uni vs std.unicode and beyond?
On Tue, 21 May 2013 14:20:50 +0100, Dmitry Olshansky dmitry.o...@gmail.com wrote: 21-May-2013 17:03, Regan Heath пишет: [snip] [snip] If we make it a part of restructuring std.* that is long overdue then I'm fine as long as package structure is well thought out as a whole. Good structure can come about from a complete top down design.. but also from many small changes towards a better whole. This is perhaps one such change? Without direction to follow there could be no end of such changes nor grief for the user and maintenance burden for maintainers. Now you're generalising. I am not suggesting we start to rename the standard library piecemeal. I am suggesting we change one module which is changing anyway combining the grief and lessening it's effect on everyone. Changing it now before adopting a package structure risks the 2nd change and another set of arguments for keeping things as is. Are we ever going to have a complete restructuring? I doubt it.. Why not - Phobos is going to grow way beyond what it's now. There has been thread on which structure to adopt but it didn't went far. And you're surprised by that? I'm not. I'm not trying to be cynical, but realistic. Realistically re-organising the standard library isn't high on the priority list, yet. So we can wait, or we can do something specific now when it'll have less detrimental effects. Meaning if we can make an incremental change for the better For better how? The endless churn in my opinion is not worth the incremental change for better. You also would have to argue for every single change with folks pushing whichever way they feel like to (not talking about uni). This is a proverbial design by committee. Another generalisation. No-one is suggesting we start renaming modules just because user X wants to. All I suggested is that if we get a chance to do so at the same time as another breaking change to the same module, we should - provided the benefit of the rename is clear. now when there is some obviation of the resulting issues then we should, or we risk more resistance in the future. Any change will leave a deprecated module that references it's new true location. Thus the less steps we do the less is damage done in the long run. Sure, and that would be ideal but the trade off is that every user has to live with badly named modules we could have changed at no additional cost to the users. Only library maintainers will see and care about the existance of the deprecated modules. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: std.uni vs std.unicode and beyond?
On Tuesday, 21 May 2013 at 12:51:05 UTC, 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. When theses pile up in a large library, this is more and more difficult to rely on intuition/autocompletion and much more on programmer's memory. It mean that it takes longer to learn the whole library. My reservations: If the chief benefit of renaming is aesthetics then I'd rather pass. This kind of knee-jerk changes made on basis of a good time to try to push a better name just don't belong in design of library/package structure. Yeah, I know nobody is going to say package structure looking at Phobos. If we make it a part of restructuring std.* that is long overdue then I'm fine as long as package structure is well thought out as a whole. Changing it now before adopting a package structure risks the 2nd change and another set of arguments for keeping things as is. Let's continue discussion here and not in voting thread. 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.
Re: std.uni vs std.unicode and beyond?
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.
Re: std.uni vs std.unicode and beyond?
On Tue, 21 May 2013 08:51:01 -0400, Dmitry Olshansky dmitry.o...@gmail.com 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. When theses pile up in a large library, this is more and more difficult to rely on intuition/autocompletion and much more on programmer's memory. It mean that it takes longer to learn the whole library. My reservations: If the chief benefit of renaming is aesthetics then I'd rather pass. This kind of knee-jerk changes made on basis of a good time to try to push a better name just don't belong in design of library/package structure. Yeah, I know nobody is going to say package structure looking at Phobos. If we make it a part of restructuring std.* that is long overdue then I'm fine as long as package structure is well thought out as a whole. Changing it now before adopting a package structure risks the 2nd change and another set of arguments for keeping things as is. Let's continue discussion here and not in voting thread. If the existing module is std.uni, then let's keep std.uni. std.unicode would be better. But the code breakage is not worth the change. As far as restructuring, I don't think it's worth the pain either. -Steve
Re: std.uni vs std.unicode and beyond?
On Tuesday, 21 May 2013 at 15:02:25 UTC, Steven Schveighoffer wrote: On Tue, 21 May 2013 08:51:01 -0400, Dmitry Olshansky If the existing module is std.uni, then let's keep std.uni. std.unicode would be better. But the code breakage is not worth the change. As far as restructuring, I don't think it's worth the pain either. Why so much reluctance? I see it rather as adding a new module to phobos, that supersedes and deprecates another module, which happens to have an undesirable name, too. If you prefer short names, I would rather go with std.ucode instead of std.uni. Frankly, look at this expansion of phobos on the left of this webpage: std.typecons std.typetuple std.uni std.uri std.utf std.uuid Does that std.uni looks right to you in this context? It is a module about unified name identifiers, isn't? Or specific to unions, those dear data structures from the old C days?
Re: std.uni vs std.unicode and beyond?
On Tuesday, 21 May 2013 at 12:51:05 UTC, 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. When theses pile up in a large library, this is more and more difficult to rely on intuition/autocompletion and much more on programmer's memory. It mean that it takes longer to learn the whole library. My reservations: If the chief benefit of renaming is aesthetics then I'd rather pass. This kind of knee-jerk changes made on basis of a good time to try to push a better name just don't belong in design of library/package structure. Yeah, I know nobody is going to say package structure looking at Phobos. If we make it a part of restructuring std.* that is long overdue then I'm fine as long as package structure is well thought out as a whole. Changing it now before adopting a package structure risks the 2nd change and another set of arguments for keeping things as is. Let's continue discussion here and not in voting thread. I would say that new module should be called std.unicode. It is way more clear what it does without looking up in docs. For code breakage, maybe public import in std.uni + pragma-msg about deprecation could lower it a bit? Restructuring Phobos is really good idea but I would say we wait for DIP15 (or any variant) so we can make transition less painful. For example std.datetime split could be unnoticeable.
Re: std.uni vs std.unicode and beyond?
Also we have std.algorithm, std.process etc and nobody complains that its name is too long.
Re: std.uni vs std.unicode and beyond?
On Tue, 21 May 2013 12:05:37 -0400, eles e...@eles.com wrote: On Tuesday, 21 May 2013 at 15:02:25 UTC, Steven Schveighoffer wrote: On Tue, 21 May 2013 08:51:01 -0400, Dmitry Olshansky If the existing module is std.uni, then let's keep std.uni. std.unicode would be better. But the code breakage is not worth the change. As far as restructuring, I don't think it's worth the pain either. Why so much reluctance? I see it rather as adding a new module to phobos, that supersedes and deprecates another module, which happens to have an undesirable name, too. If you prefer short names, I would rather go with std.ucode instead of std.uni. It has nothing to do with the name. I think unicode is better. But (allegedly) we have existing projects that use std.uni, which would break if we renamed. Even temporary relief such as an alias, deprecation, public import, etc would not be completely sufficient. Frankly, look at this expansion of phobos on the left of this webpage: std.typecons std.typetuple std.uni std.uri std.utf std.uuid Does that std.uni looks right to you in this context? It is a module about unified name identifiers, isn't? Or specific to unions, those dear data structures from the old C days? I don't disagree, but is it so bad that it's worth changing the name? That's all I'm saying, the bar has to be very high in order to require a name change. In general, changing the name of something without any added benefit (aside from the benefit of clarity) needs a very strong case to make that change. You are breaking code for no benefit to someone who doesn't care about the name. As the standard library we have to be super sensitive to these cases. -Steve
Re: std.uni vs std.unicode and beyond?
I would say that new module should be called std.unicode. It is way more clear what it does without looking up in docs. For code breakage, maybe public import in std.uni + pragma-msg about deprecation could lower it a bit? +1
Re: std.uni vs std.unicode and beyond?
On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer schvei...@yahoo.com wrote: On Tue, 21 May 2013 12:05:37 -0400, eles e...@eles.com wrote: On Tuesday, 21 May 2013 at 15:02:25 UTC, Steven Schveighoffer wrote: On Tue, 21 May 2013 08:51:01 -0400, Dmitry Olshansky If the existing module is std.uni, then let's keep std.uni. std.unicode would be better. But the code breakage is not worth the change. As far as restructuring, I don't think it's worth the pain either. Why so much reluctance? I see it rather as adding a new module to phobos, that supersedes and deprecates another module, which happens to have an undesirable name, too. If you prefer short names, I would rather go with std.ucode instead of std.uni. It has nothing to do with the name. I think unicode is better. But (allegedly) we have existing projects that use std.uni, which would break if we renamed. Wouldn't the old std.uni remain but deprecated? R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: std.uni vs std.unicode and beyond?
On Tue, 21 May 2013 12:43:01 -0400, Regan Heath re...@netmail.co.nz wrote: On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer schvei...@yahoo.com wrote: It has nothing to do with the name. I think unicode is better. But (allegedly) we have existing projects that use std.uni, which would break if we renamed. Wouldn't the old std.uni remain but deprecated? Deprecated functions don't compile. Any code that uses it would have to be modified. Only non-breaking solution would be to keep both. In the past, it has been suggested to have std.uni simply publicly import std.unicode (or analogous solution to some other module renaming). You would always retain std.uni in this solution. -Steve
Re: std.uni vs std.unicode and beyond?
On Tuesday, 21 May 2013 at 16:52:06 UTC, Steven Schveighoffer wrote: On Tue, 21 May 2013 12:43:01 -0400, Regan Heath re...@netmail.co.nz wrote: On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer schvei...@yahoo.com wrote: It has nothing to do with the name. I think unicode is better. But (allegedly) we have existing projects that use std.uni, which would break if we renamed. Wouldn't the old std.uni remain but deprecated? Deprecated functions don't compile. Any code that uses it would have to be modified. They do. Unless you add compiler switch they will compile and only spit out an warning. Only non-breaking solution would be to keep both. In the past, it has been suggested to have std.uni simply publicly import std.unicode (or analogous solution to some other module renaming). You would always retain std.uni in this solution. -Steve
Re: std.uni vs std.unicode and beyond?
On Tuesday, 21 May 2013 at 12:51:05 UTC, 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. When theses pile up in a large library, this is more and more difficult to rely on intuition/autocompletion and much more on programmer's memory. It mean that it takes longer to learn the whole library. My reservations: If the chief benefit of renaming is aesthetics then I'd rather pass. This kind of knee-jerk changes made on basis of a good time to try to push a better name just don't belong in design of library/package structure. Yeah, I know nobody is going to say package structure looking at Phobos. If we make it a part of restructuring std.* that is long overdue then I'm fine as long as package structure is well thought out as a whole. Changing it now before adopting a package structure risks the 2nd change and another set of arguments for keeping things as is. Let's continue discussion here and not in voting thread. I vote to rename it. It's hard to find for people new to phobos under the name uni (anecdotally, it took me awhile to find it when I was starting out and occasionally someone hops in IRC and asks about unicode and you typically have to point out to them that the unicode module is std.uni) I've never seen unicode called uni outside of std.uni.
Re: std.uni vs std.unicode and beyond?
On Tue, 21 May 2013 17:52:10 +0100, Steven Schveighoffer schvei...@yahoo.com wrote: On Tue, 21 May 2013 12:43:01 -0400, Regan Heath re...@netmail.co.nz wrote: On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer schvei...@yahoo.com wrote: It has nothing to do with the name. I think unicode is better. But (allegedly) we have existing projects that use std.uni, which would break if we renamed. Wouldn't the old std.uni remain but deprecated? Deprecated functions don't compile. Any code that uses it would have to be modified. dmd -d Only non-breaking solution would be to keep both. In the past, it has been suggested to have std.uni simply publicly import std.unicode (or analogous solution to some other module renaming). You would always retain std.uni in this solution. Ick no. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: std.uni vs std.unicode and beyond?
On 2013-05-21 18:25, Steven Schveighoffer wrote: I don't disagree, but is it so bad that it's worth changing the name? That's all I'm saying, the bar has to be very high in order to require a name change. In general, changing the name of something without any added benefit (aside from the benefit of clarity) needs a very strong case to make that change. You are breaking code for no benefit to someone who doesn't care about the name. As the standard library we have to be super sensitive to these cases. How about consistency? We don't want to look like PHP here. It's great that we have a review queue, DIP's and pull request. But we still have all the existing code that was there before which we need to deal with. -- /Jacob Carlborg
Re: std.uni vs std.unicode and beyond?
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. -- /Jacob Carlborg
Re: std.uni vs std.unicode and beyond?
On 2013-05-21 18:11, nazriel wrote: Also we have std.algorithm, std.process etc and nobody complains that its name is too long. They had the correct name to begin with. Why std.algorithm or std.process wasn't shortened but std.uni was I have no idea. std.algorithm is a lot newer than the others. -- /Jacob Carlborg
