std.uni vs std.unicode and beyond?

[Regan Heath]

On Tue, 21 May 2013 19:04:25 +0100, Simen Kjaeraas  
<simen.kjaras at 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 at gmail.com> wrote:
>>> 21-May-2013 17:03, Regan Heath пишет:
>>> [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 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.
>
> 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.

Agreed, we need a goal/structure to work towards.  Given that we can make  
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/