upContainers

HOLY DUNG I NEEDED TO KNOW THIS STUFF!!!

The one thing that bugs me in this library is that stacks and queues use lists instead of datums. While the maximum amount of lists that can be used in a program is relatively small and should be used with care, there can be a few billion datums active at a time.

How about going along the lines of how stacks are programmed here?

That sounds good, then. But I still think that you should use datums instead of lists.

Hi Thurnok, thanks for the input. Oddly enough, I had one of the fixes already done before you posted, but you helped point out the other function the error was also in.

Stacks and Queues can be initialized with singular data instead of lists. This saves you from creating an unnecessary list just to provide a single item for initializing your Stack or Queue.

I'm debating whether this kind of feature is useful. If someone would want to initialize a stack or a queue with only one value, it would just be as effective to call Push() or Enqueue() right after initializing it. I can't see many reasons why a programmer would want to initialize a stack or queue with one value, but if you can give me a good enough reason to add that kind of functionality, I will consider it. Ideally, I'd like to keep these data structures as bloat-free as possible, and to only add essential features.

Well, the couple of reasons I can think of off the top of my head would be:

- Code elegance for the person using the library.
- processor cycles used

For example, when using the output of some other function (assuming it doesn't output a list):
var/Stack/S = new(<somefunc>)

as opposed to:
var/list/L
L = new()
L += <somefunc>
var/Stack/S = new(L)

or:
var/Stack/S = new()
S.Push(<somefunc>)

The first alternative is obviously not as elegant plus extra overhead, the second makes two calls to the obj vice a single call. I'm not that familiar with DM yet, but in terms of C++, an IF() conditional does not take as many cpu cycles as an additional call to an object's interface function.

Also, the particular interface functions in reference execute the same statements as well as some additional ones not actually needed when creating an initial list (assuming not setting max=0). In terms of cpu cycles for initializing a Stack or Queue with a single item, I believe the code modifications I pointed out would be more effecient. This does however, have the caveat of breaking the maxlen for cases of max=0, but since there are no functions for changing the maxlen, I would think it more beneficial to prevent the occurance since I cannot imagine why one would create a Stack or Queue with a maxlen=0 unless function(s) were added for modifying a Stack/Queue length.

That being said, one would have to do some usability testing to determine if the single additional IF() statement used over the course of an entire session of an application averaged in more cpu cycles than without based on whether the app more commonly created a Stack or Queue object passing no arguments, a list as an argument, or a single value as an argument.

Either way, good stuff to have. Seems like DM would have had functions for these built-in. Perhaps a future update will, but in the mean time, nice to have this library handy.