That sounds like a bad idea. In around 95 cases out of 100 or more, you will only have one implementation of each interface, and they will live in their own components. In the case you have more than one implementation, the interfaces will delegate to different implementations within each component, so sharing interface implementation will not work anyway and I don't see the value. My advice is that you stick with the convention for some months before you change things that already work well.

makes sense

Can I say "stop fighting Polylith" again @U0J3J79FE?😁

you can , i honestly thought people were symlinking

I just checked and our interfaces are not identical across two of the three "swappable components" we have. I suspect the identical one was created in a hurry from its sibling since I needed it to fix a build/deploy bug (I blogged about this). If I revisit that one, I'll probably make changes to docstrings and some of the delegation to make it less copy-pasta and more correct.

Here's the smaller of those two differences:

<   "Record a client failure -- if we've had 'too many', then 'restart' the
<   client by creating a new Hato client and resetting the failure count."
---
>   "Record a client failure -- this is a no-op for the legacy client."
16c15
<   (impl/client-failed restartable msg))
---
>   nil)

yah it’s mostly the documentation duplication that i was after

also this is probably unrepresentative but so far o have 3 different implementations of components

so it’s triple duped

hence the question

The other diff is 120 lines, but it's mainly because it's meant to be a cut-down implementation of an internationalization component, intended to be used locally without a database, so quite a few interface fns have (assert false "This should not be called.") instead of (impl/whatever args)

We have 148 components and only 3 of those have multiple implementations. We did have a 4th but made other changes so it was no longer necessary.

And you have 3 impls of each of your components??

5 components, 2 interfaces so far

but i’m choosing most problematic stuff first to migrate

i have a giant monolith i need to chip away at

Ah, OK. And the docstrings are identical between those interfaces? Doesn't even the ns docstring explain what's unique about each particular version of the component?

it’s pretty obvious by the component name but fair point

eg interface = jetty adapter , one component for v11 and one for v12

they both take virtual-threads? in kwargs , but 11 throws unsupported op

Ah, interesting. Yes, we had a component with implementations for Ring/Jetty 9 and for sunng/Jetty 11 but we figured out another way around our "legacy app" issue. I'd probably surface that check & throw in the interface code tho', prior to delegating to the impl version.