Snippet Double-Ended Queue

[quraji]

Also, I dislike the use of modules like that, it's less flexible for sure, and limits the use of the linked list to one struct type, and to within the struct only.

I kind of agree with this. I don't mind typecasting the integer if I can use any struct type at any time. I'd personally find more use for the Linked-List Module if it worked with ints.

 

[Romek]

> I'd personally find more use for the Linked-List Module if it worked with ints.
In which case it'd be difficult to use because you'd need to work with the nodes instead of direct values.

Double-ended queues do have their uses. If you can do whatever you want to do with a double-ended queue, you'll have a much nicer and cleaner interface than what you'd have with a linked list. Really

Typecasting from structs to integers was an utterly useless point against this to make, and I'm trying to figure out why on earth J4L would say something as ridiculous as that.
Frankly, I also think that the "OMG, this simply CANNOT be approved because we've got linked list module approved" is a silly mentality.

 

[quraji]

> I'd personally find more use for the Linked-List Module if it worked with ints.
In which case it'd be difficult to use because you'd need to work with the nodes instead of direct values.

I mean if it weren't a module.

 

[Romek]

> I mean if it weren't a module.
Same problem.

 

[Jesus4Lyf]

>But Romek, please come help me find, A realistic use?
I'd be more satisfied if I could fathom a use for this. (One for which it would be preferable to the module.)

 

[quraji]

> I mean if it weren't a module.
Same problem.

I don't see how

Also, I noticed a few random occurrences of this:

            local string s = ""

 

[Romek]

> I don't see how
You'd still work with the nodes within the list instead of the values directly, as they'd have some instance methods such as .next or .prev.

> Also, I noticed a few random occurrences of this:
Thanks, fixed. That was used for debugging.

> I'd be more satisfied if I could fathom a use for this. (One for which it would be preferable to the module.)
As I mentioned before, it's difficult to find a specific use for this.
The module has many more uses than this does, as it's more complex. So it's unlikely that I'll find something like that at all.
I've already explained the difference/similarities between this and the linked list module numerous times.

 

[Bloodcount]

I suppose that some people might find this very useful. Good job, I guess.

 

[Steel]

Make a B-Tree and I'll be impressed

 

[quraji]

> I don't see how
You'd still work with the nodes within the list instead of the values directly, as they'd have some instance methods such as .next or .prev.

I know what you mean, I just don't see why you'd need to use nodes.

 

[Jesus4Lyf]

Make a B-Tree and I'll be impressed

Happened a long time ago. But it isn't balanced.

Problem is hashing just owns it, really.

 

[Romek]

Bump

 

[Jesus4Lyf]

>But Romek, please come help me find, A realistic use?
I'd be more satisfied if I could fathom a use for this. (One for which it would be preferable to the module.)

I'm listening.

>As I mentioned before, it's difficult to find a specific use for this.
>The module has many more uses than this does, as it's more complex. So it's unlikely that I'll find something like that at all.
>I've already explained the difference/similarities between this and the linked list module numerous times.

Is there a practical difference or not? I don't understand. If you would never use this over the module, why use it?

And if it is a good reason to approve one, why this over that?

 

[Romek]

> Is there a practical difference or not? I don't understand. If you would never use this over the module, why use it?
The module is overkill in many situations, and is harder to use.
You seem to have a bad habit of comparing just about everything with anything. Your system and this do similar things, but are far from identical.

> And if it is a good reason to approve one, why this over that?
That's just an annoying rip-off of this. Instead of telling me to add functions (which are now added, by the way), he remade this. Judging by the comments, O(n) adding FTL.

Edit: I think I'll add a few more methods which I've got in mind; then I'm done with this.

 

[Executor]

> And if it is a good reason to approve one, why this over that?
That's just an annoying rip-off of this. Instead of telling me to add functions (which are now added, by the way), he remade this. Judging by the comments, O(n) adding FTL.

Well you should add to your statement that I had 50% of your methods before you had them. I indeed used your basic idea, but your typename "queue" implied and implies still that this component (only) should/had have/"" the function to bring values in a specific order.

Don't blame me for you not thinking ahead enough. It is fact that you didn't mention that you want to enhance your component in some time.

 

[Jesus4Lyf]

>The module is overkill in many situations, and is harder to use.
Overkill how?

>You seem to have a bad habit of comparing just about everything with anything.
That's how I find their differences.

>Your system and this do similar things, but are far from identical.
It's not my system.

Why can't you answer the question?

>Is there a practical difference or not? I don't understand. If you would never use this over the module, why use it?

 

[Romek]

> your typename "queue" implied and implies still that this component (only) should/had have/"" the function to bring values in a specific order.
No.

> Don't blame me for you not thinking ahead enough.
I'm not blaming you for anything of that sort.

> It is fact that you didn't mention that you want to enhance your component in some time.
I didn't mention that I didn't want to enhance it either. Though I'd assume it's pretty obvious that since resources are submitted here for others to use, I (and other people) would improve/change systems to meet other peoples needs.

> Overkill how?
In most cases, this'd suffice. It's easier to use too, so this'd probably be preferred.

> It's not my system.
"By kenny! & Jesus4Lyf" - The header.

> Why can't you answer the question?
I did, it's difficult to think of any specific uses.
Some that pop into my head would be a case similar to this thread, or queueing waypoints for creeps in a TD.

It seems that you've had a negative mindset towards this from the very beginning though, Jesus4Lyf. There's no chance that you're going to approve this. Even from your very first post in this thread, you immediately suggested graveyarding this without much thought. Since then, you've just been relentlessly promoting a system with a completely different interface to this one (even to the point of writing a mocking poem doing so) without so much as considering a different point of view.

I've never seen you like this in any other thread. I do hope that this is the first and last time.

 

[Executor]

> your typename "queue" implied and implies still that this component (only) should/had have/"" the function to bring values in a specific order.
No.

translate this word in your language and you will come to the result of sth like "waiting list".

> It is fact that you didn't mention that you want to enhance your component in some time.
I didn't mention that I didn't want to enhance it either. Though I'd assume it's pretty obvious that since resources are submitted here for others to use, I (and other people) would improve/change systems to meet other peoples needs.

Ofc, but as I pointed out your system was just indented to be a waiting list with "take" and "add", so why bruising so many methods in a component, which wasn't meant to have such abilities?
Well if you don't understand my point, then I'm sorry for that.. I just can't do much more about it. But finally we have some deciding varieties [yours saves memory, mine can handle all types] and I think you won't implement this facet.


and about this topic:

It seems that you've had a negative mindset towards this from the very beginning though, Jesus4Lyf. There's no chance that you're going to approve this. Even from your very first post in this thread, you immediately suggested graveyarding this without much thought. Since then, you've just been relentlessly promoting a system with a completely different interface to this one (even to the point of writing a mocking poem doing so) without so much as considering a different point of view.

I've never seen you like this in any other thread. I do hope that this is the first and last time.

I can just agree with you Romek.
I'm not long here for myself but I really hope this isn't standard.

 

[uberfoop]

Executor, programming terms often deviate or have extra specifics as compared to their equivalents in general language. A deque is a specific form of data structure. It IS meant to be capable of doing these things if the programmer so desires.

 

[Executor]

Ofc, but wouldn't a fitting denomination make more sense?
(I know that "Field" also isn't the best way to describe my component imo this name is more undefined then "queue")