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

API design parity/uniformity: enabling of a peripheral #229

Open
datdenkikniet opened this issue May 21, 2021 · 1 comment
Open

API design parity/uniformity: enabling of a peripheral #229

datdenkikniet opened this issue May 21, 2021 · 1 comment

Comments

@datdenkikniet
Copy link
Contributor

datdenkikniet commented May 21, 2021

Hi all,

Currently, there are two types of API's being used for enabling peripherals: an Ext trait with something similar to an enable function, or a function like HalPeripheralWrapper::peripheralN(peripheralN: PACStruct).

I think it would be good if a single one of these could be picked, at least for expansions to the HAL, to ensure that the API is uniform.

Personally, I'm a bigger fan of the latter method: it's , in my opinion, clearer, and it's not necessary to import an extra trait to get the required functionality.

Perhaps changing the naming convention to HalPeripheralWrapper::from_peripheralN() would be nice, but I think that is a different discussion.

I'm interested to see what others' thoughts are on this, so please let me know below :)

@datdenkikniet datdenkikniet changed the title API design parity: enabling of a peripheral API design parity/uniformity: enabling of a peripheral May 21, 2021
@korken89
Copy link
Collaborator

Hi, there is a similar issue open which motivates that we should not have extension traits (and I agree): #57

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

2 participants