4 ms·
> but fear that there is no way to make such a thing that is usable The function declarations declare every action it can do on your system, and any change add
by marcosdumay 1y ago
> but fear that there is no way to make such a thing that is usable
The function declarations declare every action it can do on your system, and any change adding new ones is a breaking change on the library.
We've knew how to do it for ages. What we don't have is a good abstraction to let the compiler check them and transform the actions into high-level ones as they go through the stack.
- bluGill 1y agoYou end up just declaring you can do anything because every time a function legitimately needs to do something every other function up the chain needs to be updated to do that same thing (even if in practice that can never happen but the compiler can't prove it). Like you say we don't have a good abstraction for this.
- marcosdumay 1y ago> every time a function legitimately needs to do something Hopefully, you know exactly what a function needs to do when you write it. > every other function up the chain needs to be updated There are types reuse and composition to deal with that. Many languages with advanced type systems do composition badly, but it's still there.
- bluGill 1y agoThe project I work on is 15 years old. A number of functions have got more ability over the years. Low level not so much but mid and high level a lot has changed from our oririnal plan
- marcosdumay 1y agoThe ones near the top changing abilities is perfectly fine, both as a design rule and as them not leading to cascading changes in declarations through all your code. The problem is on the ones deep down. And we don't have very good tools for dealing with them, but they are perfectly workable even with what we have today. (A second large problem is on frameworks running on the top-level of your app. We have some tools for dealing with those, but the situation here is way worse than for libraries.)