npub19lwgd42k3rx9frcnvncewyjfrxlrhgpl87ktncq4h3lxnflxvccsgu3rpd (npub19lw…3rpd) There are always going to be minor changes in each implementation, though, to make it fit the context. Variable names, mostly. I don't know the tool you're talking about though, so I don't know if it's able to handle that. And when it comes to maintenance/enhancement/bug fixing, will I still be able to make the change in only one place and have it automatically propagate to all four places?
If so, then what you're describing is basically creating a single, generic, abstract function that you call from four different places. In which case, we have an accord. :-)
If not, then see my other replies: one of the biggest issues with duplicating code like that is that people change it in one place but don't know or forget that they need to change it in three others. The three other places maybe affect functionality that's not used very often or not used by very many clients, so it gets overlooked... until the next release, maybe months down the line, where it causes a show-stopping bug for a client and now we have to drop everything and work all-nighters to get it fixed. It's happened. npub1cu9expxqa5f89v9pjg3y3pglrl0x0y5sh6awy3hrp0prvmpxcp2sd26829 (npub1cu9…6829)
Graham Downs /
npub1q8…a5w8f
2024-10-10 05:12:17
in reply to nevent1q…v8ss
Author Public Key
npub1q8hnju2crm5r4fu7ystcdfav2r8etmx45nsur4le5ljjmhwj5yzs9a5w8fPublished at
2024-10-10 05:12:17Event JSON
{
"id": "44f1d52ffffa2645444dfbccf5aba17b3e0acc5edd4a327413a88c261764b771",
"pubkey": "01ef3971581ee83aa79e241786a7ac50cf95ecd5a4e1c1d7f9a7e52dddd2a105",
"created_at": 1728537137,
"kind": 1,
"tags": [
[
"p",
"2fdc86d55688cc548f1364f197124919be3ba03f3facb9e015bc7e69a7e66631",
"wss://relay.mostr.pub"
],
[
"p",
"c70b9304c0ed1272b0a1922248851f1fde679290bebae246e30bc2366c26c055",
"wss://relay.mostr.pub"
],
[
"p",
"a3592daa688e3675f0bfaee4b098afea0e53d3ed1ffd9314140c033949cf5593",
"wss://relay.mostr.pub"
],
[
"p",
"e0407bb27dd02a0cc357caf968f5feed72f2d6e18f707930a97ccb6bc1d5284b",
"wss://relay.mostr.pub"
],
[
"e",
"467dd1589d6bdf210de4ee151dbe16a61ffb1a755141b3f9af17e74462b19ec9",
"wss://relay.mostr.pub",
"reply"
],
[
"proxy",
"https://mastodon.africa/users/GrahamDowns/statuses/113281409862785662",
"activitypub"
]
],
"content": "nostr:npub19lwgd42k3rx9frcnvncewyjfrxlrhgpl87ktncq4h3lxnflxvccsgu3rpd There are always going to be minor changes in each implementation, though, to make it fit the context. Variable names, mostly. I don't know the tool you're talking about though, so I don't know if it's able to handle that. And when it comes to maintenance/enhancement/bug fixing, will I still be able to make the change in only one place and have it automatically propagate to all four places?\n\nIf so, then what you're describing is basically creating a single, generic, abstract function that you call from four different places. In which case, we have an accord. :-)\n\nIf not, then see my other replies: one of the biggest issues with duplicating code like that is that people change it in one place but don't know or forget that they need to change it in three others. The three other places maybe affect functionality that's not used very often or not used by very many clients, so it gets overlooked... until the next release, maybe months down the line, where it causes a show-stopping bug for a client and now we have to drop everything and work all-nighters to get it fixed. It's happened. nostr:npub1cu9expxqa5f89v9pjg3y3pglrl0x0y5sh6awy3hrp0prvmpxcp2sd26829",
"sig": "af3bd48e20f41cc4cb1d06b15e4ccf08fde303f614351c331ffcf0a44ee0aab813a6ad9120630d5160bd9f6d5ed2c5f84820837fbf56a59334a1a9b4a9ecc566"
}