Clojurians
#cljs-dev
<
2017-05-08
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

darwin00:05:47

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?

favila02:05:11

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

favila02:05:00

That's why the docs write it like that

favila02:05:40

Clojure script expects goog-provide-path/property

favila02:05:56

E.g. goog/DEBUG

thheller06:05:30

@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

dnolen12:05:50

the circular dependency check we have for explicit cases

dnolen12:05:12

you have an implicit case

dnolen12:05:57

an issue for that is welcome, but we’ll need a minimal repro in the ticket which will probably be somewhat challenging to construct

dnolen12:05:15

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

dnolen12:05:44

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

rauh12:05:32

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

dnolen12:05:48

@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

dnolen12:05:57

thus unlikely to make it into ClojureScript

rauh13:05:01

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?

dnolen13:05:24

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

dnolen13:05:50

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

dnolen13:05:36

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

dnolen13:05:52

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

rauh13:05:47

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

dnolen13:05:12

inlining like that is never desirable

dnolen13:05:31

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

rauh13:05:31

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

dnolen13:05:00

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

dnolen13:05:08

so no reason to prioritize that

dnolen13:05:58

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

dnolen13:05:45

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

dnolen13:05:55

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

dnolen13:05:15

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

dnolen13:05:58

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

rauh13:05:29

Personally I'd love for cljs to intern keywords. :slightly_smiling_face:

dnolen13:05:43

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

rauh13:05:17

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. :wink:

dnolen13:05:19

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

dnolen13:05:30

which why that change happened to Clojure

dnolen13:05:34

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

rauh13:05:24

Good point. I submitted: and

rauh13:05:58

Did you want a ticket about the = macro?

dnolen13:05:48

@rauh no ticket for =

favila14:05:21

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

dnolen14:05:25

I haven’t heard anything about that

dnolen14:05:03

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

bronsa14:05:17

nah, keywords are still interned in clojure

vikeri16:05:46

Exactly, ok when I get time for it I’ll try to flesh out a minimal repro and file a ticket

gfredericks17:05:45

@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

thheller17:05:59

what kind of warning do you get?

thheller17:05:41

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

gfredericks17:05:57

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

thheller17:05:46

yeah, not a good idea for a library either

gfredericks17:05:58

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

thheller17:05:00

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

gfredericks17:05:33

It should use the prefix there instead?

thheller17:05:11

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

thheller17:05:22

vs. the :require

thheller17:05:16

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

gfredericks17:05:34

I'll try that, thanks