you have no wins over just writing a plain array when it comes to usability. you still need to write out every single sub-step in the exact same order. oh but you also need to make a new struct for 0 wins.
Actually, the stack is linked and not static for the module. Yours isn't linked and is static for your array. There are some benefits there.
Also, I do it like this (unless I need to set multiple values).
set stack.push().value = value
Anyways, I'll definitely see what I can do to improve the stuff. I also edited my post to talk about the weirdness of allocator presence, so be sure to give that a read.
I'm thinking of this. This would return the created node too if you want to reference it.
stack.push(node) // no allocator
stack.push(value) // allocator
stack.pop()
stack.popv() // return value
However, the value bit would require a textmacro. There is another reason I shy away from textmacros. Modules can be nested. Macros can't.
Also, this would break for any of the table implementations because the table implementations don't use macros since they have no instance limit.
JASS:
// the reason the struct definition is included is to keep certain members private
// running the macro in an existing struct would provide access to private members for the user
//! runtextmacro DEFINE_LIST_1A1A("private", "unit", "MyList")
// the following states that an allocator is not present, so an existing struct
// is used instead
//! runtextmacro DEFINE_LIST_1A0A("private", "UnitIndex" "MyList2")
//! runtextmacro DEFINE_LIST_0A1A("private", "unit" "MyList3")
//! runtextmacro DEFINE_LIST_0A0A("private", "UnitIndex" "MyList4")
function Test takes nothing returns nothing
local MyList list
local MyList2 list2
local MyList3 list3
local MyList4 list4
local unit u = ...
set list = MyList.create()
call list.push(u)
set u = list.popv()
call list.destroy()
set list2 = MyList2.create()
call list2.push(UnitIndex[u])
set u = list2.popv().unit
call list2.destroy()
set list3 = UnitIndex[u]
call list3.push(u)
set u = list3.popv(u)
call list3.clear()
set list4 = UnitIndex[u]
call list4.push(UnitIndex[u])
set u = list4.popv().unit
call list4.clear()
endfunction
Now when we get into a table implementation, we'd need a push for each possible value. The below would likely be what it would look like.
JASS:
function Test takes nothing returns nothing
local List1T1T list
local List1T0T list2
local List0T1T list3
local List0T0T list4
local unit u = ...
set list = List1T1T.create()
call list.pushUnit(u)
set u = list.popUnit()
call list.destroy()
set list2 = List1T0T.create()
call list2.push(UnitIndex[u])
set u = list2.popv().unit
call list2.destroy()
set list3 = UnitIndex[u]
call list3.pushUnit(u)
set u = list3.popUnit(u)
call list3.clear()
set list4 = UnitIndex[u]
call list4.push(UnitIndex[u])
set u = list4.popv().unit
call list4.clear()
endfunction
Also, there are actually 16 flavors. I forgot combinations of T and A >.<. Anything that uses A would require a module/macro and would just rely on the T allocator at a central struct. Anyways, 16 flavors * 4 collection types = 64 collections - . -.
List, CircularList, Queue, Stack
gg
edit
The more I look at this, the more it smells. I think that we should just go with AA, AT, TT, and TA. Good design is good design. The lack of allocators is REALLY bad design. When you share the same instances between several unrelated things, you end up with very deep coupling and a lot of magical code that is very hard to understand. You're not sure where anything is. Yes, there is some impact to performance and some extra code, but the result is that you get some sensible collections.
The other thing is that the era of doing modules for collections is going to end with me. I'm ending them. You shouldn't be mixing up extra logic/fields with your collections. This is just bad. It is bad. It will not be done. Macros from now on. Now, some of these modules do have macros within them from other libs, and due to the lack of nesting, I'm now going to have to inline those macros. Whatever.
This will break extending collections.... it'll break it hard -.-. Adding a count to list by wrapping it up will be next to impossible. This won't be able to be addressed until we get generics (List<Type>). Until generics, we're going to have to live with this sadly : (. This means that working on a compiler as a community project should be a priority for everyone. If anyone wants to get on board with this, please let me know.
Now, back on topic. In order to get your resource approved, if your resource merits enough complexity, I do think that it should require diagrams. The moderator should not approve it just because it works. They need to be able to review your code and design. If your resource is really nasty in complexity and has no accompanying TSD, this will make the moderator's job practically impossible.