Porting serenity's command framework example about poise HOT 5 CLOSED

I used my free period at school to start this :) WIP

from poise.

Great work! Regarding sharding would it be possible to simply re-export what serenity's framework does? Unless you'd like poise to handle it differently?

from poise.

Tl;dr: I'm torn on the convenience<->simplicity trade-off

The serenity framework example accesses the shard manager from the ClientBuilder and actively writes it into the user data. In poise, both ClientBuilder configuration and user data creation are handled via callbacks from within poise, so it's a bit tricky to pass data between ClientBuilder and user data.

What I had in mind was to store the shard manager in the framework itself and make it available with a shard_manager() method or similar. User code could then just write ctx.framework().shard_manager() without any setup needed.

That plan would introduce even more magic into the framework though, which is not great. I'm still unsure about the decision to handle all framework setup by a single builder (example). It made things more streamlined but at the expense of obscuring what the framework is actually doing under the hood... Maybe the user_data_setup callback should also be removed in favor of providing a fully initialized Data struct right away. That way, you won't have access to the Ready event data, but maybe that's not needed anyways... If both the ClientBuilder and user data setup callbacks were gone in favor of direct argument passing, the serenity framework approach could be used.

Sorry for my rambling, don't feel obligated to respond to all of this haha

I'll let it rest some more, maybe a good idea will emerge

from poise.

I don't know nearly enough about poise or serenity to assess the technical challenges. However I do believe that a framework should allow the user to access the underlying primitives (or models).
Currently poise is far from feature-complete. And even if it was there would still always be edge-cases where what's provided by the framework wouldn't suffice.
Of course the goal of the framework is still to ease the development process. Hence I think the framework should allow users to access the underlying models in a usable way (ie: accessing them with at most a method and not requiring them to keep the framework updated and what they do with the primitives and data). As long as this is possible I think the focus should only be on making the framework ergonomic to use as if it wasn't used alongside anything else.
I think this would fit what you were proposing with the .shard_manager() method?

What's your designing philosophy for poise?

from poise.

In the end I decided on .shard_manager().

After making it compile, the ported example is finally pushed to the repo :) https://github.com/kangalioo/poise/blob/master/examples/serenity_example_port/main.rs

Some parts are commented out, since poise does not have support for those features

from poise.