You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 :)
The text was updated successfully, but these errors were encountered:
datdenkikniet
changed the title
API design parity: enabling of a peripheral
API design parity/uniformity: enabling of a peripheral
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 anenable
function, or a function likeHalPeripheralWrapper::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 :)
The text was updated successfully, but these errors were encountered: