Fork me on GitHub
Alex Miller (Clojure team)14:05:15

what's the story wrt reading record literals in edn in cljs? seems like they are not natively supported ( but you could maybe pass a :default to read-string that invoked the a.b/map->Foo given tag "a.b.Foo" function? or is that not possible to do in a function in cljs?


@alexmiller I thought it "worked" already?


@alexmiller yes it works and we have tests


however the limitation is that we cannot dynamically import the ns w/ that record def - so you must require it yourself before trying to use the record literal


not a horrible limitation since in many cases that sufficient for libs


can probably close that ticket


any reason that particular ticket came up on your radar?

Alex Miller (Clojure team)15:05:42

I was not able to find such a test in clojurescript. there were some tests in tools.reader but were commented out in this commit "CLJS: disable tests for non supported features"

Alex Miller (Clojure team)15:05:07

which sounds suspicious :)

Alex Miller (Clojure team)15:05:07

question from a client updating to newest clojurescript - had older working version with reader/register-tag-parser! that is not working in latest (could be some other reason too)


^ always run

Alex Miller (Clojure team)15:05:44

I'm talking about read-string


@alexmiller right read-string had issues with advanced compilation which we couldn't see through before


but this is solveable with goog.reflect


tools.reader could probably re-enable that test by going that route


read-string will try to use a name that won't exist


in advanced compilation

Alex Miller (Clojure team)15:05:41

as a cljs user, is there a way to make this work? (other than via register-tag-parser!)?


hrm I'm not sure there is an obvious way to make it work - but it should be possible yes


this is the initial implementation that allowed that to work, had to back it out due to advanced compilation munging


@alexmiller well it should be split apart really


since we have compiler support etc., and the advanced compilation thing is really a separate problem


@bronsa right but it's solveable now I believe


via goog.reflect


if you give me a hint on how to use goog.reflect I can add it back :)


@bronsa let me think about it and write up something

Alex Miller (Clojure team)15:05:14

is register-tag-parser! the best solution right now though?

Alex Miller (Clojure team)15:05:34

not trying to encourage either of you to do anything more on this now, just trying to solve a problem

Alex Miller (Clojure team)15:05:41

so don't do it on my account :)


it's always bugged me that we couldn't support it tbh, so if we now can I'm more than happy to spend some time on it

Alex Miller (Clojure team)15:05:35

@dnolen any reason why using register-tag-parser! path for record tags would have stopped working? the original issue (didn't realize it initially) is that was how it was working, but upgrade from ~1.8 era cljs to 1.10 it stopped working, still trying to debug why

Alex Miller (Clojure team)15:05:36

have checked obvious things like making sure code doing the register is being loaded before reading, etc

Alex Miller (Clojure team)15:05:10

maybe something changed on the printing side

Alex Miller (Clojure team)15:05:55

I'm just talking this out to myself

Alex Miller (Clojure team)15:05:39

what am I missing here?


cljs.user=> (reader/register-tag-parser! 'cljs.user.R  #(map->R %))
cljs.user=> (reader/read-string (str "#cljs.user.R{:a 5}"))
#cljs.user.R{:a 5}


type error :)

Alex Miller (Clojure team)15:05:07

I was coming to the same conclusion from looking at the tag-table


> however the limitation is that we cannot dynamically import the ns w/ that record def - so you must require it yourself before trying to use the record literal

Alex Miller (Clojure team)16:05:29

yeah, that's already sorted in this case