www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.uni vs std.unicode and beyond?

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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.

-- 
Dmitry Olshansky
May 21 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
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
May 21 2013
prev sibling next sibling parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Tue, 21 May 2013 13:51:01 +0100, Dmitry Olshansky  
<dmitry.olsh 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/
May 21 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
May 21 2013
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Tue, 21 May 2013 14:20:50 +0100, Dmitry Olshansky  =

<dmitry.olsh gmail.com> wrote:
 21-May-2013 17:03, Regan Heath =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
 [snip]

 If we make it a part of restructuring std.* that is long overdue the=



 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 a=


 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, b= ut = 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 chanc= e = 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 tru=

 location. Thus the less steps we do the less is damage done in the lon=

 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/
May 21 2013
prev sibling next sibling parent "Domain" <dont_email empty.com> writes:
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.
May 21 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
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.
May 21 2013
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 May 2013 08:51:01 -0400, Dmitry Olshansky  
<dmitry.olsh 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
May 21 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
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
May 21 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
May 21 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
May 21 2013
next sibling parent 1100110 <0b1100110 gmail.com> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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. =20 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.
May 22 2013
prev sibling parent 1100110 <0b1100110 gmail.com> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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. =20 Andrei

Lol, I see the talk about it on the talk now.
May 22 2013
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
May 21 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
May 21 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
May 22 2013
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
May 22 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
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?
May 21 2013
prev sibling next sibling parent reply "nazriel" <spam dzfl.pl> writes:
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.
May 21 2013
parent captaindet <2krnk gmx.net> writes:
 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
May 21 2013
prev sibling next sibling parent reply "nazriel" <spam dzfl.pl> writes:
Also we have std.algorithm, std.process etc and nobody complains 
that its name is too long.
May 21 2013
parent Jacob Carlborg <doob me.com> writes:
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
May 21 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 May 2013 12:05:37 -0400, eles <eles 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
May 21 2013
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 On Tue, 21 May 2013 12:05:37 -0400, eles <eles 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/
May 21 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 May 2013 12:43:01 -0400, Regan Heath <regan netmail.co.nz>  
wrote:

 On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer  
 <schveiguy 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
May 21 2013
prev sibling next sibling parent "nazriel" <spam dzfl.pl> writes:
On Tuesday, 21 May 2013 at 16:52:06 UTC, Steven Schveighoffer 
wrote:
 On Tue, 21 May 2013 12:43:01 -0400, Regan Heath 
 <regan netmail.co.nz> wrote:

 On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer 
 <schveiguy 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

May 21 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
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.
May 21 2013
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Tue, 21 May 2013 17:52:10 +0100, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 On Tue, 21 May 2013 12:43:01 -0400, Regan Heath <regan netmail.co.nz>  
 wrote:

 On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer  
 <schveiguy 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/
May 21 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
May 21 2013
parent "Brad Anderson" <eco gnuk.net> writes:
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
May 21 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 May 2013 13:01:57 -0400, nazriel <spam 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
May 21 2013
prev sibling next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Tuesday, 21 May 2013 at 16:52:06 UTC, Steven Schveighoffer 
wrote:
 On Tue, 21 May 2013 12:43:01 -0400, Regan Heath 
 <regan netmail.co.nz> wrote:

 On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer 
 <schveiguy 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.
May 21 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 May 2013 13:08:46 -0400, Regan Heath <regan netmail.co.nz>  
wrote:

 On Tue, 21 May 2013 17:52:10 +0100, Steven Schveighoffer  
 <schveiguy yahoo.com> wrote:

 On Tue, 21 May 2013 12:43:01 -0400, Regan Heath <regan netmail.co.nz>  
 wrote:

 On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer  
 <schveiguy 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
May 21 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 May 2013 13:21:36 -0400, Idan Arye <GenericNPC 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
May 21 2013
prev sibling next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
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.
May 21 2013
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-05-21, 16:02, Regan Heath wrote:

 On Tue, 21 May 2013 14:20:50 +0100, Dmitry Olshansky  =

 <dmitry.olsh gmail.com> wrote:
 21-May-2013 17:03, Regan Heath =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
 [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 module=

 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 sam=

 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
May 21 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
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.
May 21 2013
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 21 May 2013 16:51:01 +0400
Dmitry Olshansky <dmitry.olsh 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.
May 21 2013
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 May 2013 14:23:24 -0400, Nick Sabalausky  
<SeeWebsiteToContactMe 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
May 21 2013
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 May 2013 14:54:42 -0400, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:

 On Tue, 21 May 2013 14:33:48 -0400
 "Steven Schveighoffer" <schveiguy 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
May 21 2013
prev sibling next sibling parent "nb" <nb gmail.com> writes:
std.algo
std.uni           // Ok

or

std.algorithm
std.unicode       // OK

or

std.algorithm
std.uni          --> WTF?


- newbie
May 21 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 21 May 2013 14:33:48 -0400
"Steven Schveighoffer" <schveiguy yahoo.com> wrote:

 On Tue, 21 May 2013 14:23:24 -0400, Nick Sabalausky  
 <SeeWebsiteToContactMe 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?
May 21 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
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:

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?
May 21 2013
prev sibling next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
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.
May 21 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
May 21 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
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).
May 21 2013
prev sibling next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
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:

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.*`.
May 21 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
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)?
May 21 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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 .
May 21 2013
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Tue, 21 May 2013 19:04:25 +0100, Simen Kjaeraas  =

<simen.kjaras gmail.com> wrote:

 On 2013-05-21, 16:02, Regan Heath wrote:

 On Tue, 21 May 2013 14:20:50 +0100, Dmitry Olshansky  =


 <dmitry.olsh gmail.com> wrote:
 21-May-2013 17:03, Regan Heath =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
 [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 ever=



 single change with folks pushing whichever way they feel like to (no=



 talking about uni). This is a proverbial "design by committee".

Another generalisation. No-one is suggesting we start renaming modul=


 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 sa=


 module, we should - provided the benefit of the rename is clear.

I believe his point was rather that this time around we get std.unicod=

 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 mak= e = 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/
May 22 2013
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Tue, 21 May 2013 19:23:36 +0100, Dmitry Olshansky  =

<dmitry.olsh gmail.com> wrote:

 21-May-2013 22:12, Brad Anderson =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
 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 w=


 strings a person constantly has to guess which of these modules has w=


 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=


 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/
May 22 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
May 22 2013
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
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
May 22 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
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.
May 22 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
May 22 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
May 22 2013
prev sibling next sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
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.
May 22 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
May 23 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
May 23 2013
parent Jacob Carlborg <doob me.com> writes:
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
May 23 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
May 22 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
May 22 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
May 22 2013
prev sibling next sibling parent "Domain" <dont_email empty.com> writes:
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
May 22 2013
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
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
May 23 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
May 23 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
May 23 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
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:


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.
May 23 2013
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 21 May 2013 20:34:02 +0200
schrieb Jacob Carlborg <doob me.com>:

 On 2013-05-21 19:53, Idan Arye wrote:
=20
 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=20 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=C2=A2 ;) --=20 Marco
May 23 2013
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
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
May 23 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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 <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¢ ;)

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
May 23 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
May 23 2013