Fork me on GitHub
#rewrite-clj
<
2020-12-17
>
lread17:12:27

Ok, @vemv and @borkdude, (and any others with an interest) here’s the highlights of my current thinking on namespaced elements for rewrite-cljc. map qualifier context Symbol and keyword nodes will optionally hold map-qualifier context. This is to support sexpr on these nodes when they belong to namespaced maps. This context is automatically applied for namespaced map node children: 1. at create/parse time 2. when children are replaced this means context is also automatically applied when moving up through the zipper. namespaced map node is separate from map-node We’ll retain rewrite-clj’s namespaced-map-node (with some tweaks) for consistent node/whitespace navigation experience. Having a separate map-node and namespaced-map-node is good for generic navigation of elements, but makes accessing children for theses maps different and therefore awkward. No great ideas yet to address this well for both the raw node user and zipper user but am thinking about it. namespace auto-resolve No longer consults *ns* at all. Default auto-resolve will resolve current ns to user, ns-alias x to x-unresolved. • Am also considering defaults of ?current-ns? and ??x?? to be more in-your-face that these are not real resolutions. Any objections to these as default? Custom :auto-resolve fn is specified in optional opts arg • in node API sexpr fns • in zip API zipper creation fns. Opts are then held by zipper and automatically applied as appropriate Questions and concerns are most welcome and appreciated.

borkdude17:12:46

> Symbol and keyword nodes will optionally hold map-qualifier context. Does this mean, an extra field in the defrecord - I think so right?

borkdude17:12:10

That would have helped me in clj-kondo a while ago too

borkdude17:12:34

if we settle on a solution I will try to make clj-kondo's port as close to whatever is the decision here

borkdude17:12:16

btw, the original author of rewrite-clj is now getting sponsored by Cognitect.

lread18:12:38

> Does this mean, an extra field in the defrecord - I think so right? Yup. > btw, the original author of rewrite-clj is now getting sponsored by Cognitect. Huh! Well good for him, he made some great contributions!

lread20:12:07

Oh… I see… maybe he’ll dust off some old projects and become active again. I think I’ve reached out to him enough. He must be aware of rewrite-cljc by now and I’m sure he’ll reach out to us if he has any interest.

vemv21:12:20

> here’s the highlights of my current thinking on namespaced elements for rewrite-cljc [...] Hey there! Thanks for the ping. A bit hard for me to judge these considerations, they SGTM superficially but I'm unfamiliar with many intricacies Do you have a git branch with tests that could serve as examples? That might be a a neat way to assess capabilities, e.g. I can insert or replace various kinds of nodes. The most important fact that a git branch could convey is what you can't do, e.g. "this choice implies this tradeoff so this op cannot be supported" Needless to say, if there's nothing that's not supported, that's perfect :)

lread22:12:24

Understood @vemv, thanks for the feedback. My branch should be ready for you to try soon. I’ll ping you when it is ready for a spin!

🙌 3