Comments (5)
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.
Related Issues (20)
- 0.6.0 not on crates.io yet HOT 2
- Add support for integer and double option choices. HOT 8
- Add serenity's `CommandId` to slash commands created with poise. To reference it in the help menu HOT 1
- Add fallback message handler HOT 3
- Add an optional way to prevent docstring consumption HOT 1
- Are all examples meant to be listed? HOT 2
- Atomics - Should this be fetch_add? HOT 2
- the trait bound `poise::serenity_prelude::Context: AsRef<poise::serenity_prelude::Context>` is not satisfied HOT 9
- Handle events and still using the poise context HOT 1
- Events not firing on latest `serenity-next` HOT 1
- single-command help shows `<prefix>` for bot with no prefix
- Cannot use any parameters in context menu function HOT 3
- PopArgumentAsync isn't real HOT 1
- ArgumentParse errors from poise::command are not sanitized HOT 1
- Allow to provide a set of Team Roles, to be added to the owner array
- Rename modal title when executing from a struct that derives poise::Modal? HOT 1
- Adding attachments to initial interaction response HOT 1
- Cannot use *Id arguments like the full counterparts in prefix commands
- `Context::reply` uses old builder syntax in documentation
- CreateReply on `next` should use `impl Into<Cow<'a, str>>` instead of `impl Into<String>`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from poise.