Added Stack storage.

[itsHaseebSaeed]

As discussed here. Added stack implementation to storage-plus

[CLAassistant]

All committers have signed the CLA.

[webmaster128]

Okay, good start, thanks. I think it's still a bit too complicated becasue the type has too many features. Ideally it just does this: https://en.wikipedia.org/wiki/Stack_(abstract_data_type)#/media/File:Lifo_stack.svg, maybe plus len/is_empty/clear methods. But no change or access of data on the middle. That would be an array or linked list implementation, which is a different story.

Can you also check how the Map type works in this repo? It can be used in const places and is just a configuration how to access the contract storage. I think we should do the same here too.

[uint]

Nice job including all the tests.

I don't fully understand the use case for Stack::add_suffix. It looks like you want Stack to be both a stack implementation and a manager/factory of Stacks, all at once?

[itsHaseebSaeed]

Nice job, including all the tests.

I don't fully understand the use case for Stack::add_suffix. It looks like you want Stack to be both a stack implementation and a manager/factory of Stacks, all at once?

Suffix does what Key() does in Map. Creates new Path

[uint]

I'm wondering if it wouldn't make more sense to

1. implement a Stack that only allows you to have one stack at a fixed prefix, and then
2. think about some sort of StackMap<K, T> type to aid in managing access to multiple Stacks in a similar way Map helps in managing access to multiple pieces of data.

That way the new types have clearer purposes and the use case of "one value defined as a constant to manage multiple stacks" is still achieved.

With the current Stack implementation there might be a name collision issue too if someone actually tries to add new items to both a "root" Stack and a "derivative" Stack.

[itsHaseebSaeed]

I'm wondering if it wouldn't make more sense to

1. implement a Stack that only allows you to have one stack at a fixed prefix, and then
2. think about some sort of StackMap<K, T> type to aid in managing access to multiple Stacks in a similar way Map helps in managing access to multiple pieces of data.

That way the new types have clearer purposes and the use case of "one value defined as a constant to manage multiple stacks" is still achieved.

With the current Stack implementation there might be a name collision issue too if someone actually tries to add new items to both a "root" Stack and a "derivative" Stack.

That could be done as well. Right now, you can have or not have a suffix, it's your choice. I'll be happy to do it using Map's way. Just making sure that everyone is on board with the idea, and then I'll do a coding sprint in the coming days. Just keep on adding any other suggestions and ideas as well.

[ueco-jb]

I really like the tests.
Please update README with examples and CHANGELOG.
There are plenty of small stuff to go through - please make sure spacing between methods is one line. Currently sometimes there is none.

[uint]

Hey @itsHaseebSaeed! Are you still working on this?

[itsHaseebSaeed]

Hey @itsHaseebSaeed! Are you still working on this?

@uint funnily enough, I just added this to my weekly to-do list just today. It's will be done max by Friday then I'll start working on deque store

[uint]

@uint funnily enough, I just added this to my weekly to-do list just today. It's will be done max by Friday then I'll start working on deque store

Awesome! No hurry, just wanted to check in. LMK if you need help!

[uint]

Hey, @itsHaseebSaeed! We currently have both a need for this functionality and the resources to develop this in-house. Additionally, we might have some ideas around how to make a "map of stacks" functionality better fit our current system. Rather than spam you with change requests, we'd like to take over the implementation. Thank you for your contribution!

[uint]

Closing in favor of #807