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

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

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/

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

On Tue, 21 May 2013 14:20:50 +0100, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
> 21-May-2013 17:03, Regan Heath пишет:
> [snip]
[snip]
>>> If we make it a part of restructuring std.* that is long overdue then
>>> I'm fine as long as package structure is well thought out as a whole.
>>
>> Good structure can come about from a complete top down design.. but also
>> from many small changes towards a better whole.  This is perhaps one
>> such change?
>
> Without direction to follow there could be no end of such changes nor grief for the user and maintenance burden for maintainers.

Now you're generalising.  I am not suggesting we start to rename the standard library piecemeal.  I am suggesting we change one module which is changing anyway combining the "grief" and lessening it's effect on everyone.

>>> Changing it now before adopting a package structure risks the 2nd
>>> change and another set of arguments for keeping things as is.
>>
>> Are we ever going to have a complete restructuring?  I doubt it..
>
> Why not - Phobos is going to grow way beyond what it's now. There has been thread on which structure to adopt but it didn't went far.

And you're surprised by that?  I'm not.  I'm not trying to be cynical, but realistic.  Realistically re-organising the standard library isn't high on the priority list, yet.  So we can wait, or we can do something specific now when it'll have less detrimental effects.

>> Meaning if we can make an incremental change for the better
>
> For better how? The endless churn in my opinion is not worth the incremental change for better. You also would have to argue for every single change with folks pushing whichever way they feel like to (not talking about uni). This is a proverbial "design by committee".

Another generalisation.  No-one is suggesting we start renaming modules just because user X wants to.  All I suggested is that if we get a chance to do so at the same time as another breaking change to the same module, we should - provided the benefit of the rename is clear.

>>  now when
>> there is some obviation of the resulting issues then we should, or we
>> risk more resistance in the future.
>
> Any change will leave a deprecated module that references it's new true location. Thus the less steps we do the less is damage done in the long run.

Sure, and that would be "ideal" but the trade off is that every user has to live with badly named modules we could have changed at no additional cost to the users.  Only library maintainers will see and care about the existance of the deprecated modules.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

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.

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.

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

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?

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.