Skip to content
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

Redefine message length during construction #75

Closed
mjhouse opened this issue Apr 1, 2024 · 1 comment
Closed

Redefine message length during construction #75

mjhouse opened this issue Apr 1, 2024 · 1 comment
Assignees

Comments

@mjhouse
Copy link
Owner

mjhouse commented Apr 1, 2024

Currently, the entire size of the Message needs to be given during construction, but we may be able to avoid having the size declared using the message generics if we rebuild the message when a new word is added. So the WORD generic argument would default to 0, then a command word is added and the word is rebuilt as Message<2>, then a data word is added, and the word is rebuilt as Message<3> etc.

let message= Message::<3>::new()
        .with_command(CommandWord::new()
        .with_address(Address::Value(12))
        .with_subaddress(SubAddress::Value(5))
        .with_word_count(2)
        .build()?)
    .with_data(DataWord::new())
    .with_data(DataWord::new())
    .build()?;
@mjhouse mjhouse self-assigned this Apr 3, 2024
@mjhouse
Copy link
Owner Author

mjhouse commented Apr 3, 2024

Looks like this will only be possible if we can get WORDS (the generic param to Message) 1, which isn't easily doable without the generic_const_expr flag, which is currently unstable.

Even with this feature, we would still need a way to return a Message from a constructor function with one of two sizes, which seems difficult to do (cleanly anyway- you might be able to figure out something with enums).

@mjhouse mjhouse closed this as completed Apr 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant