There are cases where changing the I/O performance or behavior (for example, not turning off PWM) could break legacy sketches.
I have seen sketches and libraries that rely on the relatively slow performance of the current digitalWrite implementation for providing timing delays in interface code. It's not good practice, but not point in penalizing users of that code.[There are cases where changing the I/O performance or behaviour (for example, not turning off PWM) could break legacy sketches.
I have seen sketches and libraries that rely on the relatively slow performance of the current digitalWrite implementation for providing timing delays in interface code. It's not good practice, but not point in penalizing users of that code.
Yes I've also seen fragile/broken code that sometimes unknowingly takes advantage of certain code timings. I'm all about attempting to preserve backward compatibility. But developers that expect or need this are eventually going to get burned as eventually this simply can't always be done across all releases.
Trying to preserve that level of stuff is very difficult and essentually brings a toolset to a halt as any change will alter behaviors especially timing.
But even if this type of behaviour support is a requirement, then I think there are better ways to handle it than to pollute the API space with a flood of ever increasing new function calls.
A better way to handle this is to require those users that need to have this old behaviour preserved do something to request it, rather than require every one else to have to do something to request the better/new behaviour because as time goes by, those that write proper code are constantly being punished by having to update their code to use an ever changing set of API names.
So my strong suggestion would be not expand the APIs with new names for the same functions but simply write the new code such that it requires users that need to preserve an old behaviour set a #define at the top of their sketch or perhaps include some sort of deprecated or backward compatibility header file in order to get the previous existing behaviour that allows their broken code to continue to function in their specific environment. That way, the existing API is preserved for everyone and only the users that have issues with the new improved version of the code have to do anything. All those that write proper code get the new enhancements "for free".
But also, as in my previous posts, I distinguish between timing and behaviour. So for different leaned out functionality I'd rather see a layered set of API calls, so that those that want the lean and mean versions of the functionality with no hand holding (which may be faster but is different from the current behaviour) could call the _ (underbar) version of the functions of the same functions.