Formal Review of std.uni

[Dmitry Olshansky]

30-Apr-2013 04:12, Jonathan M Davis пишет:
> On Tuesday, April 30, 2013 03:02:17 Dmitry Olshansky wrote:
>> 29-Apr-2013 22:50, Jonathan M Davis пишет:
>>> On Monday, April 29, 2013 22:13:09 Dmitry Olshansky wrote:
>>>> Technically these should be in std.string and are there but incorrect.
>>>
>>> Then fix them there.
>>
>> I think it will take a certain amount of leaked implementation details
>> to get it done at least half-decently. In particular to re-use the same
>> case-folding table as for case-insensitive matching.
>>
>> Would be a strategic mistake IMHO to spread the internals across 2 modules.
>>
>> Then std.string could provide a public alias(es) as it imports std.uni
>> anyway?
>>
>> Going further if we are to preserve the status quo then std.uni will
>> declare them as package to not advertise their new location.
>
> An alias would be one option. The primary issue I see is that the general
> design of the modules has been that std.ascii and std.uni operate on
> individual characters and not strings, whereas std.string operates on strings
> (generally going with the unicode versions of things when there's a choice
> rather than the ASCII ones). And having overloads in std.uni which operate on
> strings doesn't follow that organizational model. Usually, std.string has
> called the std.uni functions to do what it's needed, and no implementation
> details have been leaked. I haven't looked at what you've done with std.uni
> yet, so I don't know how well that would work. But toLower and toUpper are far
> from them only functions which would be affected by something like this (icmp
> would be another obvious one).

Unicode --> can't be done on character by character basis

>
> But even if we decided to reorganize where some functionality or functions
> live, we shouldn't have std.uni replacing std.string functions while leaving
> the old functions in std.string. So, worst case, aliases should be used, but
> if at all reasonable, I'd prefer to keep the module organizational structure
> that we've had with regards to how characters and string functionality is
> organized.

Aliases it is then.

-- 
Dmitry Olshansky