Clojurians Log v2

With respect to a potential release: Canary is all at green. ✅ https://github.com/cljs-oss/canary

@thheller @dnolen 👋

@thheller I agree that / should always work w/ an alias but that's not really different from today

(ns foo.bar
  (:require
    [goog.string.format]
    [goog.string :refer (format)]))

(require [goog.date.UtcDateTime :as utc]) already works unless I missing something

this is one of the tricky cases

you can't leave out the goog.string.format require since then format won't exist

but the only way to alias format is using the goog.string

right I'm not sure I'm interested in that case just now

so the same case for classes

(ns foo.bar
  (:require
    [goog.foo.SomeClass]
    [goog.foo :refer (SomeClass)]))

if SomeClass is actually defined in the same file then no second require is needed

sometimes they are. sometimes they are not

right but you don't know

so :refer (SomeClass) (SomeClass/staticFn ...) seems problematic to me

also doesnt' work for any JS deps if we make it dependent on @constructor

if we just make :as directly usable for anything but CLJS namespaces most edge cases become simpler

(and we already do for JS deps, just need to extend it to Closure namespaces)

but the argument against :as is the ambiguity. (:require [some.thing :as x]) x/foo and x.foo end up with the same code but are treated differently by the analyzer

but the . handling has many other issues already so probably doesn't matter much

right but like I said it used to work this way

there were a bunch of problems when you don't know whether something is or isn't a namespace

to be honest we fixed this so long ago I don't remember all the cases anymore

I'm fine with (:import [some.thing Foo]) and (Foo/staticFn) but :refer (Foo) (Foo/staticFn) feels rather icky

yeah

and there is no ambiguity in the :import case, so that would be a no-brainer to re-implement?

yes

https://clojure.atlassian.net/browse/CLJS-3177

I guess we could add that for a nnext release and ponder about the other :refer issue some more (or not)

yeah

why is this supported in CLJS (and diverging from Clojure), is there a real need for it?

(set! (js-obj "a" 1) -a 2)

(https://clojure.atlassian.net/browse/CLJS-198)

to be honest I've never seen it used in the wild, but probably because not a lot of people know this exists?

(set! thing -a 2) is nicer than (set! (.-a thing) 2) IMHO

maybe Clojure should support it as well 😉

set! is a weird beast 😛

@borkdude I think maybe Fogus did that short-hand bit?

in JVM Clojure you mean? I don't know btw

I mean the ClojureScript behavior

oh: https://github.com/clojure/clojurescript/commit/8b37ace4ae7d780515ad1255b64597e50adc7507

oh ha

so old

so I did that

yeah I did it so threading would work for all the mutable APIs

it came up here: https://twitter.com/mfikes/status/1181708123511373827

I've just fixed linting this set! variant in clj-kondo, but re-linting CLJS itself doesn't seem to have an effect on the amount of false positives. Maybe it's not used anywhere?

(I'm not linting the test sources)

Would an issue like https://github.com/bhauman/figwheel-repl/issues/10 be something that the latest CLJS release’s lib analysis tool would uncover?

@tkjone on a plane so I can't the see link for some reason - but is the issue that Figwheel has a typo?

Yes. Figwheel is referencing glog/warn as opposed to glog/warning.

so yeah

but the release does more of course

What was interesting is that I only got the warn when using latest CLJS

REPL support, var existence check, arity checking, return type propagation

and tooling could hook into - we record file / line / column info for each def

I haven’t sorted out the root cause, but unit tests failed on Windows: https://clojure.atlassian.net/browse/CLJS-3178

definitely a bit skeptical that 3137 could be the cause at the moment

Yeah—it seems it could be an unrelated sporadic failure.

Yes, it was a sporadic failure---rebuilding it causes it to pass.

weird that it can randomly fail. we have problems with advanced compilation on JVM11 + boot (although the errors there are not random)