Queue

[Moderocky]

Description

Please note: this is just one of a number of experiments, it may never see the light of day.

We were poking around with some collection ideas.
I thought about a queue, because it's annoying to make with list variables.
Removing an element leaves its index open, meaning the next addition to the list will fill the empty spot, so you'd have to re-set the list each time you change an element.

The queue is a First In, First* Out collection. That means you take items out from the start, and add them to the end.
It's a regular type rather than a variable, and you don't have direct access to its indices in terms of setting and getting as you might with a Skript list.
Queues are super fast for adding to and removing from, but less efficient for random access.

These queues don't support empty (null) values either, so adding something that doesn't exist will have no effect. A queue should never contain an empty (null) value either, which means that if you ask for a value and you get nothing, the queue must be empty.

Creating a queue

set {queue} to a new queue
set {queue} to a new queue of {things::*}
set {queue} to a new queue of "a", "b" and "c"

Adding to a queue

set {queue} to a new queue
add "hello" to {queue}
add {words::*} to {queue}
# really not rocket science, this...

It's also possible to add specifically to the start (or the end) of a queue.

set {queue} to a new queue
add "world" to {queue}
add "hello" to the start of {queue}
# values in order will be hello and world

Reading a queue

This uses ExprElement, but popping a queue removes the element you ask for.

set {thing} to the first element of {queue}
broadcast the first element of {queue}
broadcast the first element of {queue}
# each time we do this, it's popping the next value out!

set {words::*} the first 6 elements of {queue}
# removes the first 6 values

broadcast the last element of {queue}
# bye bye last value

You can also "peek" at the starting and ending values of a queue.

set {thing} to the start of {queue}
set {thing} to the end of {queue}
# this "sees" the element but doesn't remove it

Dequeueing

Queues can be converted to/from list variables easily.

set {items::*} to unqueued {queue}
set {queue} to a new queue of {items::*}
set {items::*} to dequeued {queue}

Neither of these deletes or affects the other, it just rolls/unrolls the values.

Checking whether a queue is empty

This has compatibility with the is empty condition.

if {queue} is not empty:
    # ...

Asking for an element of the queue will also return nothing if it is empty.

Indices & Setting

You cannot (currently) get the indices of an element, set an element at an index, or check whether a queue contains something.
This is not designed to be an equivalent/replacement list type, and these operations are all fairly inefficient for linked collections so I didn't want to encourage their (mis)use. You can, of course, still swap between queue -> list -> queue and do them all that way (at your own peril!)

Notes

The intentions around it were to make some odd bits and pieces easier, such as:

set {queue} to a queue of all players

while <the game is running>:
    set {player} to the first element of {queue}
    # it's player's turn now!!!
    # do their board game stuff
    # player had their turn
    add {player} to {queue}
    # now they're at the back of the queue

It'll definitely be a lot easier/more efficient than list variables for some things, but I also don't want this to be abused as a list-replacement so I'll have to consider whether it's a safe feature to add.

---

Target Minecraft Versions: any
Requirements: none
Related Issues: #371

[sovdeeth]

I've gone back and forth on this in my head, but I think that this approach is probably the best, as opposed to new variable types. It's a bit of a departure for people (me) used to lists and how they look in skript, but considering how other languages approach data structures it makes a lot more sense for us to just have one variable type and multiple structures that can go inside them, with common syntaxes to access them. I would eventually like to see us rework the list syntax into a more generic structure (perhaps {list::index} could access maps, arrays, or queues: {map::key}, or {array::1}, or {queue::first}), but that's out of scope here.

I'll do a code review shortly, just wanted to share my high level thoughts.

[sovdeeth]

looks solid, though i'd like more tests for invalid behavior like nulls, and docs for the queue classinfo

[APickledWalrus]

Here's what I found. As for whether this should be implemented, I think it is worth consideration.

Also, does this support size of {queue}?

[APickledWalrus]

A few other things. This is shaping up nicely

[APickledWalrus]

bump (this can be replaced with an expressions[0] != null check