3 ms·

On the other hand, it's really difficult to know who is using that shared code. If you make an innocuous change in a shared method, it could affect someone else

On the other hand, it's really difficult to know who is using that shared code. If you make an innocuous change in a shared method, it could affect someone else you don't know.

TheCoelacanth 6y ago
It's very easy with proper tooling.
BoiledCabbage 6y ago
Outside of publishing a public API almost any modern language and enviroment should make this easy.
bcrosby95 6y ago
It's a million times easier than figuring out if those minor differences in duplicate code are accidental or on purpose. As bad as a flag-laden method might be, you know the intent of all callers.
mcintyre1994 6y ago
I find it much easier to find the call sites for a function than to find code that’s duplicating or a variant of the code I just fixed a bug in so we can figure out if the same bug is latent in the duplicates too.
dtech 6y ago
Not in any modern language or IDE. Not to mention that would indicate a hole in the test suite
lambdatronics 6y ago
It doesn't have to be that way, it's just because our existing language facilities don't have support for what we need them to do: "Names are regularly repurposed to point to new definitions, even when the old definitions are still perfectly valid. For instance, a library author might make a function a bit more generic by adding an extra parameter, or decide to switch the parameter order. That's fine, but the old definition was not wrong, so should users be forced to upgrade? No. Repurposing names is fine; it's hard to come up with good names for definitions, so using an old name for a related new definition often makes sense. The trouble is that existing tooling doesn't distinguish between repurposing a name and upgrading a definition. Unison changes that..." https://www.unisonweb.org/2020/04/10/reducing-churn/#incompatible-library-versions https://www.unisonweb.org/2020/04/10/reducing-churn/#incompa...

On the other hand, it's really difficult to know who is using that shared code. If you make an innocuous change in a shared method, it could affect someone else you don't know.

TheCoelacanth 6y ago

It's very easy with proper tooling.

BoiledCabbage 6y ago

Outside of publishing a public API almost any modern language and enviroment should make this easy.

bcrosby95 6y ago

It's a million times easier than figuring out if those minor differences in duplicate code are accidental or on purpose. As bad as a flag-laden method might be, you know the intent of all callers.

mcintyre1994 6y ago

I find it much easier to find the call sites for a function than to find code that’s duplicating or a variant of the code I just fixed a bug in so we can figure out if the same bug is latent in the duplicates too.

dtech 6y ago

Not in any modern language or IDE. Not to mention that would indicate a hole in the test suite

lambdatronics 6y ago

It doesn't have to be that way, it's just because our existing language facilities don't have support for what we need them to do: "Names are regularly repurposed to point to new definitions, even when the old definitions are still perfectly valid. For instance, a library author might make a function a bit more generic by adding an extra parameter, or decide to switch the parameter order. That's fine, but the old definition was not wrong, so should users be forced to upgrade? No. Repurposing names is fine; it's hard to come up with good names for definitions, so using an old name for a related new definition often makes sense. The trouble is that existing tooling doesn't distinguish between repurposing a name and upgrading a definition. Unison changes that..." https://www.unisonweb.org/2020/04/10/reducing-churn/#incompatible-library-versions https://www.unisonweb.org/2020/04/10/reducing-churn/#incompa...