Interesting. I just read through it. My immediate thought is that I'm not really seeing what the benefit of namespace inheritance would be. Didibus mentioned that it's used in Phoenix to make defining models/views/controllers more convenient. Although Biff doesn't really follow MVC as far as I'm aware, the equivalents (schema, ring handlers, ui code) seem pretty easy to define already? If I was more familiar with Phoenix/elixir I might have a clearer understanding of why it's helpful there and why or why not it might be helpful in biff. I think namespace inheritance is possibly a separate issue from whether or not the framework actually provides inversion of control (as was correctly pointed out, biff still follows the standard Clojure practice of keeping the "framework" code in your app rather than in an external library). Again at this stage it's not obvious to me that there would be any benefits to having Biff's feature maps work more like plugins. the very first release of biff did use a plugin system actually--you annotated namespace with ^:biff metadata and then biff discovered them at runtime. but later I removed it because it didn't really provide any value over the current explicit approach. I guess in summary--both ideas sound like they're still in the exploratory/"what if" stage. Before I implemented either of them, I'd need to come up with/have someone else come up with some concrete examples of how it'd help in biff. E.g. it might be interesting to copy the code from one of platypub's feature namespace into a gist and then rewrite it to how it might look if biff implemented these things. These are definitely the kinds of things I like thinking about in any case :).

Yes, Fact is: decision in favor of „inversion of control“ over „Library“ definitely must come before the choice of pattern to do it („ns inheritance“ etc). The catch is: As far as I read didibus he is wandering in his post if the Clojure practice of „Library“ might have been established exactly because of this Fact and its modus tollens. The Fact that decision for „Inversion“ implies „choice of Inversion pattern“ means also that if there is no known „Inversion pattern“, then the „Library“ approach follows with logical necessity. Now you say that in fact you did try ^:biff metadata „pattern“ for „Inversion“ and discarded it, so at least you kicked the tires of this modus tollens trap. But you also express the opinion that there is sense in kicking tires again after a while. I.e. someone coming up with a github repo showing a „pattern“ that could be chosen after „Inversion“ has been decided.

that's a good way to put it!

@U7YNGKDHA , this removed ^:biff annotation keeps praying on my mind. Would you allow me to quote you from above ("at this stage it's not obvious ... explicit approach.") in the Clojureverse post? Or (much better) post yourself? I know, you are the one who makes things (instead of talking "what if" stuff) and it takes up a lot of your time. But posting is a small step compared to making the community leap to discussing a concrete discarded inversion example.

Sure, just posted it: https://clojureverse.org/t/namespace-inheritance-a-la-elixir-use-using-is-this-madness/9199/41?u=jacobobryant

Thank you so much. Whenever I spot someone saying "Clojure needs a boring Web Framework" I'll point to this post and ask "How would you introduce inversion of control in this case?". Soon people will realise how epoch-making this ^:biff step and its reversal was.