std.xml should just go

[Andrei Alexandrescu]

On 2/7/11 12:02 PM, BLS wrote:
> On 06/02/2011 16:41, Andrei Alexandrescu wrote:
>> On 2/5/11 17:54 EST, BLS wrote:
>>> On 04/02/2011 04:20, Andrei Alexandrescu wrote:
>>>> Cool. Is Michael Rynn willing to make a submission?
>>>
>>> He announced a while ago in d.announce. std.xml2 candidate.. A few weeks
>>> earlier (if am not completely wrong) he offers his implementation for
>>> phobos.
>>
>> We need to improve the formalism of submissions to Phobos. The first
>> successful instance of that is std.datetime - a model we should follow.
>>
>>> Regarding ranges.
>>> - Ranges of ranges which are IMHO needed for any kind of non linear
>>> data-structures (say:everything which contains a node) seem to be very
>>> difficult to handle.
>>
>> Feel free to discuss. (I'll note that that would only further my
>> obsession with ranges...)
>>
>>> -I could further argue that Steven is still using cursors in
>>> dcollections, but well, you already know that :)
>>
>> Cursors are an addendum to ranges, not a replacement.
>>
>>
>> Andrei
> Will send you an email containing a skiplist based rudimentary
> dictionary container.

I appreciate that, but it's not worth making me the bottleneck on a 
topic of general interest. You should post here.

> Nothing special so far but interesting 'cause its
> Node-Structure contains node[]. (or node*[] // )
>
> Since skiplists are pretty simple datastructures, at least compared to
> some self balancing tree algorithms, it would be an excellent
> opportunity to show how ranges work on data-structures. In practice.
>
> IMHO, we need again a new a discussion regarding how to implement
> containers.
> 1- concurrent/ non concurrent containers

For now concurrent containers are considered completely different beasts 
from non-concurrent ones.

> 2- Isn't it cleaner to have std.adt // abstract datatypes like rbtree,
> avl, whatever nodes, graphs

I don't think so.

> 3- final class vs struct

Looks like final class is a bit cleaner.

> 4- Constraints vs Interfaces

That's tied to 2; I think interfaces are a poor fit for the variety of 
containers that are out there.

> 5- What about container events ?

A container that emits events upon change should be a parameterized 
non-final class that takes the container C as a parameter and exposes 
the same methods as C with events in tow.

> bjoern
> ps
> Despite that, due to the fact that the QT folks *prefer to implement
> their dictionary container based on skiplists, this structure is
> probably worth to become part of phobos.

Skiplists fit the philosophy of std.container very well.


Andrei