VLERange: a range in between BidirectionalRange and RandomAccessRange

[Andrei Alexandrescu]

On 1/17/11 12:23 PM, spir wrote:
> Andrei, would you have a look at Text's current state, mainly
> theinterface, when you have time for that (no hurry) at
> https://bitbucket.org/denispir/denispir-d/src
> It is actually a bit more than just a string type considering true
> characters as natural elements.
> * It is a textual type providing a client interface of common text
> manipulation methods similar to ones in common high-level languages.
> (including the fact that a character is a singleton string)
> * The repo also holds the main module (unicodedata) of Text's sister lib
> (dunicode), providing access to various unicode algos and data.
> (We are about to merge the 2 libs into a new repository.)

I think this is solid work that reveals good understanding of Unicode. 
That being said, there are a few things I disagree about and I don't 
think it can be integrated into Phobos. One thing is that it looks a lot 
more like D1 code than D2. D2 code of this kind is automatically 
expected to play nice with the rest of Phobos (ranges and algorithms). 
As it is, the code is an island that implements its own algorithms 
(mostly by equivalent handwritten code).

In detail:

* Line 130: representing a text as a dchar[][] has its advantages but 
major efficiency issues. To be frank I think it's a disaster. I think a 
representation building on UTF strings directly is bound to be vastly 
better.

* 163: equality does what std.algorithm.equal does.

* 174: equality also does what std.algorithm.equal does (possibly with a 
custom pred)

* 189: TextException is unnecessary

* 340: Unless properly motivate, iteration with opApply is archaic and 
inefficient.

* 370: Why lose the information that the result is in fact a single Pile?

* 430, 456, 474: contains, indexOf, count and probably others should use 
generic algorithms, not duplicate them.

* 534: replace is std.array.replace

* 623: copy copies the piles shallowly (not sure if that's a problem)

As I mentioned before - why not focus on defining a Grapheme type (what 
you call Pile, but using UTF encoding) and defining a ByGrapheme range 
that iterates a UTF-encoded string by grapheme?


Andrei