Also we have std.algorithm, std.process etc and nobody complains that its name is too long.

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

> 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

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/

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

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

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.

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/

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

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