-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
[Merged by Bors] - Complete inline documentation for bevy_audio #3510
Conversation
9bfa358
to
2d14fc5
Compare
2d14fc5
to
e15bd25
Compare
@@ -43,9 +50,12 @@ impl AssetLoader for Mp3Loader { | |||
} | |||
} | |||
|
|||
/// Mark a type as decodable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could use more information about what exactly it means for something to be "decodable".
Many of the readers will have 0 audio experience.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find it very hard to specify because this trait is so generic. There is no restriction on the Decoder type in the trait.
The restrictions come later in the implementations of AudioOutput and Audio. There we require the Decoder to yield some rodio types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved the trait bounds from the implementations to the decodable trait. Now it should be a bit clearer what the trait means and we have a lot less duplication in where clauses.
This is not the same API, but I couldn't think of a use case where it would be a problem to have the rodio trait bounds on the Decodable trait directly.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will lead to a little bit of generic-pollution, but the boilerplate reduction and clarity are worth it here IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, this is looking good! I particularly like #[forbid(unsafe)]
: we should have that pretty much everywhere.
A couple questions and nits for you.
pub bytes: Arc<[u8]>, | ||
bytes: Arc<[u8]>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why removing the pub
? doesn't it allow someone to generate an audio source instead of loading it from a file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. I made it public again.
bors r+ |
# Objective Part of #3492 - Complete inline documentation of `bevy_audio` ## Solution - Added inline documentation to all public parts of `bevy_audio` - Added a few inline examples at important places - Some renaming for clarity (e.g. `AudioLoader` and generics) - added `#![warn(missing_docs)]` and `#![forbid(unsafe_code)]` to `bevy_audio` I also tried adding support for the other vorbis file endings `.oga` and `.spx` to the `AudioLoader` (see `file endings` at https://tools.ietf.org/html/rfc5334#section-10.3), but the `rodio` decoder does not seem to support those.
Objective
Part of #3492
bevy_audio
Solution
bevy_audio
AudioLoader
and generics)#![warn(missing_docs)]
and#![forbid(unsafe_code)]
tobevy_audio
I also tried adding support for the other vorbis file endings
.oga
and.spx
to theAudioLoader
(seefile endings
at https://tools.ietf.org/html/rfc5334#section-10.3), but therodio
decoder does not seem to support those.