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 reply 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
parent reply "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]


[snip]

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






n

 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=




lso

 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=


e  =


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


g  =


 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
parent reply "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]


 [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 module=


s  =


 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=


e  =


 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
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]


 [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 ever=






y  =


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






t  =


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


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




es  =


 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=




me  =


 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=


e.

 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 reply "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
parent reply "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
parent reply "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
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:


 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.
May 23 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
parent reply "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
parent reply "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
next sibling parent reply "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
parent reply "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
next sibling parent reply "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
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 reply "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
parent reply "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
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 "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
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:
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.


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


=20
 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 reply "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
parent reply 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
next sibling parent reply "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:


 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?
May 21 2013
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:


 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.*`.
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 "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 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=




ith

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




hat

 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/
May 22 2013
prev sibling parent reply 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
parent reply 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.


=20
 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
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 reply "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
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 parent reply "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
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 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 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 "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 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
next sibling 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 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 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
parent reply "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
parent reply 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
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 reply "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
parent reply "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
parent reply "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
next sibling parent reply "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
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 parent reply "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
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 "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
parent reply "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
next sibling parent reply "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.



for years, I still don't know what some modules are about in 
phobos.

Yeah, it is worth it.
May 22 2013
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.



 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 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 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
next sibling 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 reply 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
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 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
prev 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