Fork me on GitHub
#duct
<
2020-09-02
>
rickmoynihan07:09:58

Does anyone know why integrant’s composite-keyword function appends a gensym’d value to the end of the composite key? I know these return values are memoized, but I was thinking about using them as a stable id across JVM restarts, though obviously can’t because of this. Obviously it’s easy to generate a unique composite myself; so not a big deal, just curious what the reasoning was.

Kevin07:09:48

I think it's just an easy solution to make it unique

rickmoynihan07:09:09

Isn’t it a unique unambiguous value without the gensym though?

Kevin07:09:30

You'd have to take all the keywords, stringify them, and then create a new keyword out of that, in order to make it unique

Kevin07:09:55

Ah right but the parts are also part of the new key

Kevin07:09:23

The only thing would be that: [:foo.bar/baz] and [:foo/bar.baz] Would both result in the same key (in the function's current form, without gensym)

Kevin07:09:59

But that could be fixed

Kevin07:09:17

(I think)

Kevin07:09:48

I think technically speaking you could always create duplicate keys without gensym. But you could make it very difficult

rickmoynihan07:09:36

Yeah I think the problem is that ig/loadnamespaces allows :foo.bar.baz and :foo.bar/baz to resolve to the same thing

Kevin07:09:06

That's one problem, the other is that when creating a new composite keyword, it joins the name and namespace with a .

rickmoynihan07:09:48

yeah but that later one is easily solved by changing the implementation of composite-keyword

rickmoynihan07:09:08

well I say easily solved… I guess there is a small issue that most characters are usable in a keyword

rickmoynihan07:09:55

though actually you could leverage using unreadable characters there e.g. even (keyword "foo bar") would work (though not recommending that one) actually ignore all that.