โข we have some datomic transaction functions defined in polylith components.
โข they have to be referenced in transaction data with their fully qualified symbols.
โข they have to be defined in .interface namespaces though, to expose them to polylith bases.
โข that makes the already long, qualified tx-fn names significantly longer, degrading readability considerably
1. is there a way to exempt such function from under this convention somehow?
2. has anyone came up with a circumvention of this inconvenience?
3. do poly users typically redefine these verbose conventions in real-world systems? if yes, what are popular alternatives as a synonym for interface? i think the docs mentioned ifc
btw, in Hong Kong context IFC means https://en.wikipedia.org/wiki/International_Finance_Centre_(Hong_Kong)
api can be another alternative
or just i ๐
on 1 - if you can put them in a base (perhaps by potemkin import) you can use shorter namespaces, bases are less restrictive in this sense
yes, i saw that recommendation about using bases, BUT their drawback is that other bricks can't depend on bases, only poly projects. right?
yep
I think you can put the transaction functions or refer to them in a namespace with whatever you like as long as you don't require this namespaces in any component. I did this for a different use case and polylith doesn't complain
so you can have a proxy namespace to an interface one if you want to test them or use in other components
Also Polylith doesn't complain if you have an "illegal" inline require . So not generally a good practise but this way you can bend the rules a bit
@jeroenvandijk thanks. very interesting suggestions.
the (require 'tx.fn.ns) is quite naughty ๐
but at least we can have an explicit indication of the code dependencies that way, which both humans and i assume LLMs can benefit from too.
hmm. If you only need the function names in the other component, you could create a function in the interface which returns the fully-qualified shorter symbol of the real function