maybe put mutable and immutable under different namespaces?

hmm no then we're just pushing that choice off onto the user

One realization I had later is that using the munged names is actually good if you want to use this stuff from CLJS

I'm not super clear on why?

because then you can write:

(:require ["clavascript/core.js" :refer [assoc-in!])

or :as clava + clava/assoc-in!

oh, and it knows how to handle the BANG and underscores. cool

but also... why would you want to use that from cljs?

to work with js structures directly I guess?

yeah, this issue is probably not that important, the primary use case for the lib is to be used from clavascripts...

makes sense, thanks for explaining:)

hmm. i can remove the + function from that PR

I think I might know what's going on, perhaps. It's a weird interaction between advanced compilation and this PLUS function that was added, but perhaps maybe only in the test build...

Instead of 1 + 2 + 3 the compiler now generates 1 _PLUS_ 2 _PLUS_ 3 as if the stringified symbol is optimized to the munged version

i was wondering how special form and function collisions would work. i was happy to see that it both generated infix when it could and used the function when passed as a value in test

yes, in call position it prefers the inline thing

Link to gist or something? We can extract the preview code to a script that can print something prettier if the code has an error, or something that colors the output if the user has bat, etc installed

yeah, this was what I ended up going with https://gist.github.com/lilactown/11027faf1f48408e9861be9aed2abc52

Just for fun: brew install bat echo '' | fzf --preview './read-eval-print {q} *| _bat -l javascript_*' --preview-window Lmk if that looks interesting to ya

What's the benefit of doing this over using the browser playground?

idk, I've been using the CLI

maps are used when you need to use non-string keys, mostly. objects have all sorts of pitfalls around keys like automatic conversion to strings and the potential for prototype pollution, too

> a = {}
{}
> a[1] = 2
2
> a
{ '1': 2 }
> b = new Map()
Map(0) {}
> b.set(1, 2)
Map(1) { 1 => 2 }
> b
Map(1) { 1 => 2 }

:thumbsup:

I'm just breezing through some calva code realizing that there are probably instances that would be vulnerable to prototype pollution due to the use of objects instead of maps 😬

So, most JS APIs work with objects right? Are you using Maps for like say, internal app data?

yes, exactly that

Would you say that using #map {[1 2 3] [4 5 6]} would be a nice notation?

like in clojure you mostly use maps with string or keyword keys but sometimes you need lookup maps using keys that aren't either of those

(bad example probably since you don't look up arrays by equality but by reference, but just for the idea)

I think #map { key1 val1 key2 val2 key3 val3 } if that's what you mean

and like you just hinted, you need to be really careful with reference equality

yep

also yep

in one of my recent projects we hand-rolled a deep-equals map

isn't it about time you just include immutablejs or lodash etc then?

we have lodash, but it doesn't give you a deep-equals map (where the keys are compared with deep-equals)

isEqual doesn't support that? hm

https://gist.github.com/corasaurus-hex/892041882a81f7fcfe3723f243da6fa0

we use isEqual in there

I see

it's gross but it gets the job done (for sufficiently small maps where this nonsense isn't too expensive)