Refactor poolify function

[lundibundi]

@tshemsedinov I'm not sure for the changes here but I don't see merit in 'poolify'ing functions and having to always pass an array to pool in order to place them back in the pool. With this it is not possible to poolify the functions but you can simply call pool(item) to put the item back in the pool.

If we have some good usage for poolify with functions I'll just remove the removal of support for them and this PR will only contain the remaining refactorings.

• move items/delayed to closure instead of saving them on a function
• rename helper functions to a more sensible names
• remove support for functor-poolify and remove tests

[lundibundi]

I used Array.isArray to distinguish get and put items.

Yes, I understood that, and the only reason for that IIUC is to have functions in a pool (or pool from functions). But I couldn't see any merit in having functions in a pool. In this https://github.com/metarhia/metasync/pull/376/files#diff-368334117fc46ee4b155e68d0966c0ecL97 test the pool will contain functions generated from their index in a pool, but what can it be used for?

[tshemsedinov]

We may hold closures and functors in pool because many abstractions may be implemented as instances of Function type

[lundibundi]

Could you clarify what sorts of abstractions may need to use Function, as I cannot come up with any?

[tshemsedinov]

@lundibundi for example we may write any system code or business logic with async contracts composed with metasync asynchronous composition that generates instances of Function type. We may want to use closures like objects for instantiation, so there are multiple cases.

[nechaido]

Closed due to inactivity, feel free to reopen this when the work is resumed.