This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-10-04
Channels
- # announcements (6)
- # babashka (7)
- # beginners (2)
- # biff (5)
- # calva (2)
- # cherry (17)
- # cider (3)
- # clj-kondo (8)
- # clojure (202)
- # clojure-brasil (8)
- # clojure-europe (20)
- # clojure-norway (23)
- # clojure-uk (4)
- # clojuredesign-podcast (5)
- # conjure (1)
- # cursive (9)
- # eastwood (22)
- # events (8)
- # fulcro (3)
- # hyperfiddle (22)
- # introduce-yourself (7)
- # lsp (67)
- # malli (1)
- # matrix (1)
- # meander (6)
- # off-topic (76)
- # pedestal (8)
- # polylith (17)
- # quil (12)
- # re-frame (2)
- # reagent (8)
- # releases (3)
- # shadow-cljs (67)
- # sql (93)
- # squint (39)
- # tools-deps (46)
- # vim (7)
As always I'm very thankful to the polylith structure and tool 🧡 . However, if I could change two things (perhaps there are already functions/workarounds I am unaware of) they would be 1️⃣ Allow components that are not swappable to avoid having the boilerplate of an interface. Avoid Error 101: Illegal dependency on namespace xxxxxxxx in yyyyyyyyy. Use xxxxxxxx.ifc instead to fix the problem
. If and when I need that component to be swappable (of which I have a few), then I'll do the work to upgrade it. 2️⃣ Allow interfaces to be suffix-able i.e. mycomponent_ifc.cljs
rather than having many files called ifc.cljs
as it means IDE integration/file search would be so much easier. 🙏
Actually I realise that 2 will make 1 less frustrating and vice versa 😄
The poly tool understands the interface namespace and ensures that components do not depend on each other freely; instead only use their interfaces. As a result, the workspace is less entangled.
The poly tool supports using interface prefix. You can create a directory named interface (or ifc, in your case) and place namespaces inside that directory. The names paces become x.y.z.ifc.my-ns-1
, x.y.z.ifc.my-ns-2
etc.
Regarding 2️⃣ I do use the directory prefix. I'd prefer a file prefix as it makes search easier (that's the nature of the post). I would type in Regarding 1️⃣ I will then simply have to endure a large number of errors, where I don't regard adding the boilerplate as adding value to my life. My life would be better if there was a switch on specific components to hide those errors.mycomponent...
in emacs search. Instead I type in ifc...
and get a wall of entries (due to me often relenting on 1).
Apologies! I see you mean include the ifc
in the directory. I read it wrong. I'll have a think.
Thanks
@U03B2SRNYTY You can put the full implementation in the */ifc/*.clj*
file to avoid "boilerplate" if you want.
At work we have a few interface.clj
files that contain the implementation instead of also having a impl.clj
(but mostly that's a result of refactoring from non-Polylith code and we just haven't gotten around to separating out the actual interface from the implementation).
@U04V70XH6 Completely agree about full implementation in the ifc
file, and with the suggestion above can have a meaningful name. What I liked about Clojure development compared to Java was the abandoning of an overly nested package structure. Clojure namespaces catered to many exposed symbols in very flat directories. The equivalent were deep nested directories in Java at my previous enterprise stack. Having an ifc
directory feels a little like a regression to that state. I'll have to adopt tree
instead of ls
...
We have 200 deps.edn
files, just to give you a sense of scale. Most of our components are just two src files: ws/<component>/interface.clj
and a corresponding impl.clj
- we tended to have more nesting before we moved to Polylith.
@U2BDZ9JG3 Morning. How do you get poly create..
to create an ifc
dir instead of the reverse? The default behaviour obscures the option.
The create
command is not very flexible. I'd love a way to change the layout/structure of what it produces by default. Things I change in every component immediately:
• remove resources
(and update :paths
in deps.edn
)
• remove entire test
folder
• add copyright to interface.clj
Then I code for a while in the REPL, maybe create impl.clj
and refactor.
• run a shell script to generate stub test
files (without failing test, with our copyright, without requiring clojure.test
, with a (:require [<interface-ns>]) ; :as sut
line in ns
(SUT is an old, old habit from my early TDD days many years ago -- so all tests always have (sut/my-fn ...)
as the system/service under test).
I think it would be really nice to have templates for new bases, components, and projects, either in .polylith/templates/...
in the workspace or ~/.config/polylith/templates/...
in the user home directory.
I've been tempted to add something to deps-new
for this (`clj-new` has a Polylith template that is closer to my preferences but it's a "whole project" creator -- deps-new
is more amenable to adding features to an existing project).
I've seen sut
before. Source under test, correct? 😂
Source/system/service, yeah.
I have a bad habit of not reading long lines, completely.
(yikes, XP is about 30 years old at this point)