-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ADD PDResultSuccessEmpty #86
ADD PDResultSuccessEmpty #86
Conversation
So a disadvantage is that you are forced to handle the new result kind also for the two responses that have a non-optional response: getScoreboards and getScores. We could work around this by having two sets of types: PDRequiredResult + PDRequiredResultKind vs PDOptionalResult + PDOptionalResultKind. That feels over-engineered. Feeling lukewarm about that, let's not do it. Unless you know of some fancy Nim feature that lets us express this nicely? @Nycto |
Well — let’s start with: what are we modeling here? Is it actually a failed request (like WiFi unavailable)? If so, why don’t the other requests include this response state? |
Yeah, I guess the unavailable response is always relevant. Made the change to Unavailable |
By using the Scoreboards API for Wheelsprung, it feels wrong to classify a result without data as an error.
Therefore I added an extra PDResultKind for this and documented the cases where this may be returned to the callback