Fork me on GitHub

Hi folks, I just found it, seems to see really relevant to understand why fully-qualified keyword is a important thing:


This little library beautifully illustrates this concept:


Nice, I’ll check it carefully.


Yeah, it’s very small and simple. But I think it is helpful to think about the implications of such a library, why it is useful to exist, why it becomes more useful the more it is used. It has in some sense an essential relationship to interfaces and traits in (other) languages. And in this particular instance it is also interesting that it’s about communicating errors across boundaries, as in “here is the thing that happened and here is what it means”, very informal and non-enforcing. It’s just about language and information, not mechanism.


I do tend to consider a trade-off that's not always obvious: most of the time, I don't interop with external systems that are also Clojure systems. Also, most of the time, I'm working on really small Clojure systems. This translates to lots of translation between external JSON data to internal, and back. On most of the projects I work with, this is not sustainable - a change on schema means touching code that, to be honest, is just moving data around and not doing anything of value.


That being said, Pathom did change my view a little bit. I still don't use qualified keywords for everything, but I do namespace external payloads over a "big map" like :external/user, for example, with a single value that's the full map. This makes things somewhat easier, and if I do need some more complex transformations, I'll add into a resolver with full qualified keyword

👍 2

Yes @U3Y18N0UC, I think that Luke mentioned it, and seems that it may have more value when building big modular systems, but not much value when building distributed systems that do a lot of communication using external means (http apis/grpc, message queues, etc)


I mean, distributed systems that are composed by tyne services with hundred lines of code at most.