From my naive point of view I would think js/goog.x.y.z should mean the same thing as goog/x.y.z, but it doesn’t anymore for some reason, going through goog pseudo-namespace still works as before… that raises a question why is goog special?

@mikethompson closure-defines passes through to gcc, which expects the js dotted-path form

That's why the docs write it like that

Clojure script expects goog-provide-path/property

E.g. goog/DEBUG

@gfredericks you should probably file a JIRA issue. if you are just after the fix in goog.math.Integer you can put that into your source path and it will override the one from the jar

@mikethompson goog.DEBUG vs. goog/DEBUG is a bit of a detail but yes the later is preferred

@rauh the polyfill idea is welcome as well as the additional language options, but these should be separate tickets

@dnolen Great! Will submit two ticket. Any opinions on the condp change? It wouldn't break anything

@rauh to be honest it doesn’t really seem that important to me, and I don’t know how likely that is to make into Clojure

thus unlikely to make it into ClojureScript

One more idea: It's extremely common in all CLJS code to check for keyword equality. "`(= x :end)`". If = were turned into a macro we could dispatch to keyword-identical? when one of the arguments is a keyword literal and there are two arguments. Thoughts?

adding special case to = for this doesn’t sound that attractive to me

however applying that trick to identical? seems useful since it would actually correspond to a manual optimization in Clojure

it would have been clever to do that when we introduced keyword-identical? but just never occurred to me

so I would be interested in the later - and we should stew on the former

@dnolen You mean transform (identical? :a/b x) => ((x instanceof Keyword) && x.fqn === "a/b")

no

inlining like that is never desirable

I just mean identical? -> keyword-identical? is all

I see. That makes sense. Though I think mostly people use =, so that'd be a nice speedup since it's so common.

but = being fast for keywords like this in Clojure isn’t a real expectation anyway

so no reason to prioritize that

however fast Clojure does exists that uses identical? for keyword checks, and that creates portability friction

anyways the bigger point is just that later fixes something I know people have been working around

the former thing is just nice to have but not essential in my opinion

hrm though now that I think a bit more deeply about it I’m not so sure about identical? behaving in this way

since doing that would make it appear that identical? works in 2 different ways - so yeah this is not a good idea 🙂

Personally I'd love for cljs to intern keywords. 🙂

probably not going to happen since there’s no way to do a reasonable WeakMap for JS in general

Yeah I know, though early versions of Clojure didn't use Weakref's IIRC. And if somebody is dynamically creating keywords in cljs then he/she deserves all the memory problems. 😉

well the issue more that a malicious attacker is hitting your webservice creating keywords a la Ruby

which why that change happened to Clojure

anyways probably not going to do any new stuff here - we ended up where we ended up after much consideration

Good point. I submitted: and

Did you want a ticket about the = macro?

@rauh no ticket for =

I thought identical? for keywords was bad practice in Clojure now? Something about relaxing intern guarantees?

I haven’t heard anything about that

in anycase I would strongly suspect that won’t get very far given the amount of existing code

nah, keywords are still interned in clojure

@thheller that's what I've been doing for the last year or so, but with recent versions of cljs I'm getting warnings from it and was hoping to not have to figure out why

or something similar to that at least: https://github.com/gfredericks/goog-integer

what kind of warning do you get?

https://github.com/gfredericks/exact/issues/1

hmm no idea sry. having another Integer impl seems like a bad idea but should still work

Given that this is a library, using the same name would be brittle w.r.t. classpath order, wouldn't it?

yeah, not a good idea for a library either

Would an alternative be to write code that monkeypatches the Integer class?

I think the warning is because extend-type com.gfredericks.goog.math.Integer

It should use the prefix there instead?

you are aliasing the class, (:import [com.gfredericks.goog.math Integer]) and then just Integer

vs. the :require

or extend-type alias/Integer .. but I'm not sure how you'd alias that

I'll try that, thanks