std.uni vs std.unicode and beyond?

[Regan Heath]

On Tue, 21 May 2013 14:20:50 +0100, Dmitry Olshansky  
<dmitry.olsh at 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/