View mode: basic / threaded / horizontal-split · Log in · Help
February 19, 2012
std.collection lets rename it into std,ridiculous.
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
February 19, 2012
Re: std.collection lets rename it into std,ridiculous.
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.
February 19, 2012
Re: std.collection lets rename it into std,ridiculous.
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
February 19, 2012
Re: std.collection lets rename it into std,ridiculous.
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
February 20, 2012
Re: std.collection lets rename it into std,ridiculous.
Maybe when you learn to type like an adult people will listen to 
you?
February 20, 2012
Re: std.collection lets rename it into std,ridiculous.
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...
February 20, 2012
Re: std.collection lets rename it into std,ridiculous.
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. ?
February 20, 2012
Re: std.collection lets rename it into std,ridiculous.
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)
February 20, 2012
Re: std.collection lets rename it into std,ridiculous.
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.
February 20, 2012
Re: std.collection lets rename it into std,ridiculous.
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 ?
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home