std.uni vs std.unicode and beyond?

[Dmitry Olshansky]

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