3 ms·
> All your replies about external APIs changing are irrelevant. A codeveloper touching functions that call your functions or defining functions called by you wi
by powatom 13y ago
> All your replies about external APIs changing are irrelevant. A codeveloper touching functions that call your functions or defining functions called by you will integrate with your work with an innocuous "git pull" and force you to review everything just to rule out what JS could have easily detected.
Everything that you didn't write yourself is an external API for all intents and purposes - you're using somebody else's code, regardless of whether that person 'owns' the code or not. The fact remains that if you're relying on a function and somebody changes it without considering the consequences, then that's a process issue, not a JS one. In the same way, if you're writing code which others may depend on, then you need to consider the potential consequences of your changes.
> Again, I'm not talking about "dependencies" or libraries here at all.
The point is that you should be talking about dependencies and libraries. The situation you're describing is one in which code is not properly modularised and organised - where any developer can change any function and thereby fuck up the rest of the project. If your code was organised properly, these problems would disappear.
> The push was completely benign. The integration of that push with your current work will be broken in cryptic ways. Not necessarily ones that show up in the testing suites.
You keep using the word 'will'. I'm telling you with hand on heart that this problem does not happen if you sort out your development team and project structure.
> Every single function signature can break things, not just exposed APIs.
Yes, it can break things, but it shouldn't.
> Two developers might work on the same piece of code. There's not necessarily any obvious point to notify here and still breakage may arise.
If two developers can't work on the same area of code without stepping all over each other, then you need to look at how you're structuring your code.
> 1) Developer A adds a new function FOO that calls internal function BAR in his unpushed working tree.
> 2) Developer B changes the signature of internal function BAR, and pushes this change to "master".
> 3) Developer A pulls from master, his code is now broken, but JS doesn't even warn him when he executes it. Instead, wrong results (or accidentally correct results for any given test case) arise.
> 4) The test suites don't catch the error. Developer A unwittingly pushes the broken code to master.
Why is developer B changing the signature of function BAR willy nilly? Code isn't written in isolation and your changes have an effect on other developers. If you have a function which is being used by other people - then you have a public API. You don't break an API randomly.
- Peaker 13y agoSo basically you need to use strict ownership at API boundaries as that is the only way to avoid this. This isn't always optimal. It sounds like you're sacrificing quite a few goats at the js altar for no real benefit. Your question about why a developer would need to change an internal function's signature is ridiculous. Maintaining code involves changing function signatures all the time. If another developer is working within the same API boundary, he's screwed. This isn't a necessary fact of life. Even most sane dynamic language will error out when such incompatibility arises, instead of blaming the developer for using a process incompatible with the js way. Not to mention the other argument, that with all the discipline in the world, humans will still make mistakes. Instead of translating to errors, they translate to bugs. The gain? not having to use an asterisk when you want varargs. That's just stupid.
- powatom 13y ago> So basically you need to use strict ownership at API boundaries as that is the only way to avoid this. This isn't always optimal. It sounds like you're sacrificing quite a few goats at the js altar for no real benefit. No, but when somebody I'm working with makes a potentially breaking change to a shared codebase, they either ensure that they also fix the now broken code, or they flag it up to the people whose responsibility that is. Aside from that - most people simply avoid making a breaking change - or if it absolutely must be made, then a process is followed. > Your question about why a developer would need to change an internal function's signature is ridiculous I wasn't asking why the developer was changing a function signature - rather why they're so eager to change a function signature without following up and either fixing the things they break, or flagging those things up to the people who require it. > This isn't a necessary fact of life. Even most sane dynamic language will error out when such incompatibility arises, instead of blaming the developer for using a process incompatible with the js way. There's no such thing as a random error. If there's an error, somebody made a mistake. Some mistakes are stupid, others are subtle. Changing a method signature and then not doing something about the callers is a stupid mistake. > Not to mention the other argument, that with all the discipline in the world, humans will still make mistakes. Instead of translating to errors, they translate to bugs. Of course humans will make errors - but your job is to minimise the frequency and severity of those errors. There's no excuse for sloppiness - you either keep on top of shit, or you don't. Call it whatever you like, but a shitty broken codebase is only the fault of the developers, not the language.