Remove requirement to have Reader when decoding attributes and write anything converted to Event #760
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR includes two changes, which both related to my work of splitting event into two event classes -- for reading and for writing. Events for reading then would only borrow data and this will help to fix #332 and also open doors to
no_std
reader (not sure why it would be needed although).The first commit just removes unused import that I noticed while working on this.
The second commit relaxes requirements for decoding values from
Attribute
. If you created attribute for writing and then for whatever reason wants to read its value back, you need aReader
which you does not have. This commit fixes that.The third commit makes writing methods take
Into<Event>
instead ofAsRef<Event>
. The former trait give a lesser abilities thenInto
. It allows you to pass your own struct to write, but you need to have event in your struct to be able to take a ref to it.Into
would allow you to construct event on demand and also would allow to directly pass reader event to the writer method that would require writer event if (when?) event splitting will be implemented. In any case, I think, that takingInto
is better.If there are any objections, then unnecessary commits can be removed from PR.