On 14/01/11 02:25, Steven Schveighoffer wrote:
> On Wed, 12 Jan 2011 04:49:26 -0500, Steven Wawryk <[email protected]>
> wrote:
>
>>
>> I like the direction you're taking but have some quibbles about
>> details. Specifically, I'd go for a more complete separation into
>> random-access code-unit ranges and bidirectional code-point ranges:
>
> Thanks for taking the time. I will respond to your points, but please
> make your rebuttals to the new thread I'm about to create with an
> updated string type.
>
>> I don't see a need for _charStart, opIndex, opSlice and codeUnits. If
>> the underlying T[] can be returned by a property, then these can be
>> done through the code-unit array, which is random-access.
>
> But that puts extra pain on the user for not much reason. Currently,
> strings slice in one operation, you are proposing that we slice in three
> operations:
>
> 1. get the underlying array
myString vs myString.data
> 2. slice it
Same for both.
> 3. reconstruct a string based on the slice.
myOtherString = find(myString, 'x');
vs
myOtherString = find(myString.data, 'x');
You may see extra pain. I see extra control. The user is making it
explicit at what level (code-unit/code-point/grapheme/whatever) of range
he/she wants the called algorithm to be working on.
> Plus, if you remove opIndex, you are restricting the usefulness of the
> range. Note that this string type already will decode dchars out of the
> front and back, why not just give that ability to the middle of the
string?
Because at the code-point level it *isn't* a random-access range and the
index makes no sense at the code-point level, only at the code-unit
level. It's encouraging the confusion of 2 distinctly different
abstractions or "views" of the same data. All the slicing and indexing
you're artificially putting in the code-point range is already available
in the code-unit range, and its only benefit is to allow the user to
save typing ".data".
- other Steve
