February 20, 2012
On 02/19/2012 04:48 PM, Bernard Helyer wrote:
> 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.

Mo excuse. Be assured, and there is no doubt  that I will name shit SHIT. I live in a free country.
Any substantial feedback ?

February 20, 2012
On Monday, 20 February 2012 at 01:01:16 UTC, bls wrote:
> 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 ?

You are the one getting all emotional about the std.ridiculous module. Besides, where do yoy (ha!) get that I know how to design it?

Strawman too much?
February 20, 2012
On 2/19/12 4:05 AM, bls wrote:
[snip
> The std.collection situation is a shame,

I understand your frustration, and you are entitled to it. This std.container situation has gone on forever. It's all my fault. I know what to do, but work and family put great demands on my time, and I find it very difficult to focus on good design in the bits and pieces of time I have left.

A quick and dirty set of containers will unfortunately not help. Such designs have inevitably caused more problems for us than they solved (xml, json come to mind). We need to do the right thing.


Andrei


February 20, 2012
>> 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.
>
>
> Mo excuse. Be assured, and there is no doubt  that I will name shit SHIT. I
> live in a free country.
> Any substantial feedback ?

However, claiming such a thing only lowers peoples opinion of you. Other people that use the "I live in a free country" defense include thugs that intimidate people and teenagers disagreeing with their parents. If that is your only defense, then you clearly don't have a defined reason for holding your opinion.

As for your writing, it is obvious that you are french, however, that does not excuse 1) casual mixing languages in writing, you might speak like that, but this isn't verbal conversation. 2) rudeness. Bad manners are bad manners, regardless of language and 3) not proofreading, a few typos here and there are ok, especially if English is not your first language, but you don't even punctuate properly, and I /know/ that French has the same punctuation rules as any other Latin-derived language.

My feedback is that for most people's purposes, associative arrays and arrays (dynamic and static) are fine. PHP doesn't have a well-used collections library (though it does exist) but it is used by millions of sites every day. I don't normally need an explicit queue/stack/priority queue.

James Miller
February 20, 2012
On Mon, Feb 20, 2012 at 04:19:10PM +1300, James Miller wrote: [...]
> My feedback is that for most people's purposes, associative arrays and arrays (dynamic and static) are fine. PHP doesn't have a well-used collections library (though it does exist) but it is used by millions of sites every day. I don't normally need an explicit queue/stack/priority queue.
[...]

The convenience and flexibility of D's arrays have, for the most part, replaced my need for explicit stacks or queues. For example, here's a stack:

	T[] stack;
	void push(elem) {
		stack ~= elem;
	}
	T pop() {
		T elem = stack[$-1];
		stack = stack[0..$-1];
		return elem;
	}

Here's a queue:

	T[] queue;
	void enqueue(elem) {
		queue ~= elem;
	}
	T dequeue() {
		T elem = queue[0];
		queue = queue[1..$];
		return elem;
	}

It's so trivial to implement that it's hardly worth the effort to implement a class for it.

Your mileage may vary, though.


T

-- 
Some ideas are so stupid that only intellectuals could believe them. -- George Orwell
February 20, 2012
On 20 February 2012 16:43, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> On Mon, Feb 20, 2012 at 04:19:10PM +1300, James Miller wrote: [...]
>> My feedback is that for most people's purposes, associative arrays and arrays (dynamic and static) are fine. PHP doesn't have a well-used collections library (though it does exist) but it is used by millions of sites every day. I don't normally need an explicit queue/stack/priority queue.
> [...]
>
> The convenience and flexibility of D's arrays have, for the most part, replaced my need for explicit stacks or queues. For example, here's a stack:
>
>        T[] stack;
>        void push(elem) {
>                stack ~= elem;
>        }
>        T pop() {
>                T elem = stack[$-1];
>                stack = stack[0..$-1];
>                return elem;
>        }
>
> Here's a queue:
>
>        T[] queue;
>        void enqueue(elem) {
>                queue ~= elem;
>        }
>        T dequeue() {
>                T elem = queue[0];
>                queue = queue[1..$];
>                return elem;
>        }
>
> It's so trivial to implement that it's hardly worth the effort to implement a class for it.
>
> Your mileage may vary, though.
>
>
> T

The cool thing about that implementation is that, by using slices, you generally avoid allocation, unless its neccessary.
February 20, 2012
On 02/19/2012 04:21 AM, bls wrote:
>
> Any substantial feedback ?
>

http://docs.python.org/tutorial/datastructures.html#using-lists-as-stacks
February 20, 2012
> here's a
> stack:
>
> 	T[] stack;
> 	void push(elem) {
> 		stack ~= elem;
> 	}
> 	T pop() {
> 		T elem = stack[$-1];
> 		stack = stack[0..$-1];
> 		return elem;
> 	}

Won't this reallocate every time you pop an element and then push a new one?


February 20, 2012
On Mon, 20 Feb 2012 14:05:07 +1100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> We need to do the right thing.

Do we? Really?

That takes sooo loooong it encourages many home-baked-reinvented-wheels that might very well end up taking more time and effort from the community than incrementally creating a standard set of containers.  Does it really matter if our initial efforts for some of the expected data structures are less than 'The Right Thing'? If they meet 80%+ of our requirements and continue to evolve towards perfection, I'm pretty sure the community could cope with a NQR product for now.

-- 
Derek Parnell
Melbourne, Australia
February 20, 2012
On Monday, 20 February 2012 at 10:44:03 UTC, Derek wrote:
> On Mon, 20 Feb 2012 14:05:07 +1100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> We need to do the right thing.
>
> Do we? Really?
>
> That takes sooo loooong it encourages many home-baked-reinvented-wheels that might very well end up taking more time and effort from the community than incrementally creating a standard set of containers.  Does it really matter if our initial efforts for some of the expected data structures are less than 'The Right Thing'? If they meet 80%+ of our requirements and continue to evolve towards perfection, I'm pretty sure the community could cope with a NQR product for now.

You could use dcollections ( http://www.dsource.org/projects/dcollections ) if you need something now.