Hi
What's  the problem to implement some very basic containers ?
And No !! Don't waste time to tell about built in Arrays and Associative arrays, I am following D for at 5 years now..

What I definitely don't get is
queues, stacks and dequeues, and also specialized kind of  stacks/queues  don't depend on ranges. Why we don't habe them.
Everybody, using D for serious purposes, is creating home brewed stuff.

But fuc da duc..

the whole Range collection stuff is completely undefined.

All we know right now is that Algorithms are working on data-structures. (Pretty new, beside)

//First incarnation ..
public class Deque(T)
{
    private class Node()
    {
        T _value;
        Node _previous;
        Node _next
    }
}
Yep..
should be

final public class Deque(T)
{
}

We are still not there ..
struct Node()

final class Deque(T, alias allocator)
{
}
// Let's range-i-fy it ... and here we are

final class Deque(T, alias allocator) : IXXXRange|T
{
 // push and pop without sense.. what is enqueue now ?
}

Shit. all I want is a generique Queue

The std.collection situation is a shame,
Bjoern

On Sunday, 19 February 2012 at 22:55:05 UTC, bls wrote:
> Hi
> What's  the problem to implement some very basic containers ?
> And No !! Don't waste time to tell about built in Arrays and Associative arrays, I am following D for at 5 years now..
>
> What I definitely don't get is
> queues, stacks and dequeues, and also specialized kind of  stacks/queues
>  don't depend on ranges. Why we don't habe them.
> Everybody, using D for serious purposes, is creating home brewed stuff.
>
> But fuc da duc..
>
> the whole Range collection stuff is completely undefined.
>
> All we know right now is that Algorithms are working on data-structures. (Pretty new, beside)
>
> //First incarnation ..
> public class Deque(T)
> {
>     private class Node()
>     {
>         T _value;
>         Node _previous;
>         Node _next
>     }
> }
> Yep..
> should be
>
> final public class Deque(T)
> {
> }
>
> We are still not there ..
> struct Node()
>
> final class Deque(T, alias allocator)
> {
> }
> // Let's range-i-fy it ... and here we are
>
> final class Deque(T, alias allocator) : IXXXRange|T
> {
>  // push and pop without sense.. what is enqueue now ?
> }
>
> Shit. all I want is a generique Queue
>
> The std.collection situation is a shame,
> Bjoern

Eagerly waiting your contribution, preferably through a pull request, to remedy this unfortunate situation.

On 02/19/2012 03:40 PM, Yao Gomez wrote:
> Eagerly waiting your contribution, preferably through a pull request, to
> remedy this unfortunate situation.

OK,
Will do. All I need is guide to Range-Interfaces. (and a good reason why I should iterate over stacks and queues)

But wait. Despite that : Are final classes the way to go ? I don't know. Is it written in the sand or is it the new golden rule ?

What about the allocator ? Who knows... But shit isn't dcollections showing the way how to implement flex. allocator on demand. ?

You know it. Everybody is able to contribute to std.collections. But thanks to the ignorance here and there, std. collection is still a joke. Period.

Bjoern

On Sunday, February 19, 2012 02:05:18 bls wrote:
> Hi
> What's  the problem to implement some very basic containers ?
> And No !! Don't waste time to tell about built in Arrays and Associative
> arrays, I am following D for at 5 years now..

std.container is where containers/collection go. The main reason that we don't have more is that Andrei is working on the design for custom allocators which will have a definite impact on the containers. So, rather than create a bunch of container types which are going to have to be  redone later, we just don't have very many.

At least we have _something_ now (it was quite a while before we got std.container), and much of the basics of how containers are supposed to look like and work have been ironed out, but the allocator situation is proving to be a roadblock. However, not very long ago, Andrei said something about having a breakthrough in his work on the allocator design, so we may be seeing custom allocators - and thus more containers - fairly soon.

- Jonathan M Davis

Maybe when you learn to type like an adult people will listen to you?

On 20 February 2012 13:05, Bernard Helyer <b.helyer@gmail.com> wrote:
> Maybe when you learn to type like an adult people will listen to you?
>

Its also worth mentioning that most structures are simple enough that for 99% of purposes, a "homebrew" implementation is fine. I was taught how to implement a queue and a stack at the same times as using it, that is how simple some of these containers are. And if you need massive speed, then you probably wouldn't use generic containers anyway...

On 02/19/2012 04:05 PM, Bernard Helyer wrote:
> Maybe when you learn to type like an adult people will listen to you?
>

Facts, that's what I am are talking about. If you don't like my speak ...sorry.
My point is that D2 needs asap a working container/collection lib
(and I think the "How to allocate/de-allocate" question becomes more and more ridiculous.  That Stuff is meanwhile library based.. Typedef f.i.)

So why not plug- in an allocator. ?

On 02/19/2012 04:20 PM, James Miller wrote:
> On 20 February 2012 13:05, Bernard Helyer<b.helyer@gmail.com>  wrote:
>> Maybe when you learn to type like an adult people will listen to you?
>>
>
> Its also worth mentioning that most structures are simple enough that
> for 99% of purposes, a "homebrew" implementation is fine. I was taught
> how to implement a queue and a stack at the same times as using it,
> that is how simple some of these containers are. And if you need
> massive speed, then you probably wouldn't use generic containers
> anyway...

Sure thing.. for a while, What if you have to manage a bigger piece of software, 20 peiple project . Would nt it be better to use a "default container" having a dedicated interface. Sanity wise ?
--
But this is not my point. I think that std.container/collection is a shame (to whom it may concern)

On Monday, 20 February 2012 at 00:29:20 UTC, bls wrote:
> On 02/19/2012 04:05 PM, Bernard Helyer wrote:
>> Maybe when you learn to type like an adult people will listen to you?
>>
>
> Facts, that's what I am are talking about. If you don't like my speak ...sorry.
> My point is that D2 needs asap a working container/collection lib
> (and I think the "How to allocate/de-allocate" question becomes more and more ridiculous.  That Stuff is meanwhile library based.. Typedef f.i.)
>
> So why not plug- in an allocator. ?

When you use words on the internet people judge you based on your words. There's more to proposals than technical merits, and if you don't understand that that's fine, but don't be surprised when people dismiss you quickly. People filter information because they have to -- they'll take any excuse to ignore you. Don't make it _easy_ for them.

On 02/19/2012 03:40 PM, Yao Gomez wrote:
> agerly waiting your contribution, preferably through a pull request, to
> remedy this unfortunate situation.

Still waiting for an answer.. Show me the Quality assurance table for collections.
This can't be difficult for You, since yoy know how to design it.. And finally there is SList, Still En Voque ?