is it true that (:require [foo.bar :include-macros true]) causes the :include-macros true clause to effectively be implicitly present for requires of foo.bar in every other namespace?

yes, kinda accidentally. https://dev.clojure.org/jira/browse/CLJS-2454

it is not something you should rely on

I was hoping to rely on the opposite

you can maybe blow the analyzer state but I wouldn’t recommend it 😉

Is the whole implicit sugar thing just a variant of this?

it doesn't matter how the macro namespace is loaded. once it is loaded it will always be used.

maybe the question is: you should not rely on CLJS-2454, but isn’t the implicit sugar thing exactly this?

not really. the :require-macros sugar ensures that the macros will be loaded and accessed properly

without you are relying one something doing :include-macros true somewhere at least once in your build

isn’t include-macros true just sugar for require-macros?

(https://clojurescript.org/guides/ns-forms#_sugar)

yes, but in a different place. it is added to the consumer ns, not the provider ns .. for the lack of better words ...

I see, so there is a different mechanism in self-requiring in the provider ns, or requiring the macros from a consumer ns?

(ns foo.consumer
  (:require [foo.thing :include-macros true]))

(ns foo.consumer
  (:require-macros [foo.thing])
  (:require [foo.thing]))

with the "self-require" the consumer does not need any knowledge of whether there are macros or not

so it is shifted to the provider of said macros

(ns foo.consumer
  (:require [foo.thing]))

(ns foo.thing
  (:require-macros [foo.thing]))

Understood yeah. But if a consumer ns1 would have used require-macros [foo.thing], could consumer ns2 get away with not doing that and still use the macros from foo.thing without a self-require? It seems to be that it’s the same mechanism (getting the analyzer in the right state), so I don’t get why you should not rely on it in CLJS-2454.

as I said above

> it doesn't matter how the macro namespace is loaded. once it is loaded it will always be used.

yes, but “you should not rely on it”, that’s the part what I’m asking about effectively 🙂

you should not rely on it unless you can guarantee that the ns with the "side-effect" of loading the macros will ALWAYS be loaded first

right, it’s brittle because of that.

ok, clear.

🙏

tl;dr: requiring macros in CLJS is side-effecting (once a var is identified as a macro, it stays a macro), so you should not rely on the order of loading namespaces. better is to do a self-require, then the side effect happens predictably and at the right time. is that a good summary?

yes

A question related to key and val. In Cljs 1.9, it used to work when we called key or val on a 2 element sequence. Now in Cljs 1.10 it breaks. I know that calling key or val on a seq is not accurate but it used to be tolerated. What’s the rationale of this breaking change?

I don't know anything about cljs, but I'd say that is fixing something broken

alignment with Clojure probably

I know key and val would work on vectors, but really sequences?

did this maybe change when MapEntry was introduced as a proper type in CLJS? Before that 2-element vectors were used.

it's related to that change

but I am surprised that even then (key (list 'a)) would have worked

Most recently merge-with was also brought up to date using MapEntry which broke secretary, the client side routing lib

(key ['a']) definitely would have worked, and that stopped working because of MapEntry

rather, because a proper MapEntry type was introduced to align with clojure

yes, it’s also more performant (I’ve heard)

that wasn't really the motivation

I said also 🙂 (nice bonus)

https://dev.clojure.org/jira/browse/CLJS-2013

this just added the type. the real work was done later

Here’s the patch for merge-with, showing some perf benefits: https://dev.clojure.org/jira/browse/CLJS-2943

i.e. converting PHM PAM etc to produce and consume them, and fixing key and val

cool.

In the app of my customer, there are hundreds of occurences of key, val and vals

I am very tempted to add an implementation of IMapEntry for all the sequences. Something like:

(extend-protocol IMapEntry
  PersistentVector
  (-key [v] (first v))
  (-val [v] (second v)))

It feels like a dangerous hack

Any thoughts?

could work as an intermediate solution to an upgrade. emit a warning in those implementations and fix them one by one?

@viebel I am really suspicious about your claim that any seq could use key and val

as far as I can see and remember, only PersistentVector implemented IMapEntry until https://github.com/clojure/clojurescript/commit/620ac16d93a91786e1c636fac1269ed66087aa03/src/main/cljs/cljs/core.clj

I get a 404

https://github.com/clojure/clojurescript/commit/620ac16d93a91786e1c636fac1269ed66087aa03 ?

I had some junk at the end sorry

CLJS-2478 is the ticket

as of that commit, PV no longer implemented IMapEntry

but before that commit only PV and MapEntry implemented IMapEntry

and the key and val functions have always only immediately called -key and -val

the idea with key and val is that they are "slots" in a tuple, directly accessible via a lookup (not a traversal)

MapEntry is a custom 2-tuple for it

vectors are plausible (as slots with direct access)

seqs are right out and you should feel bad if you did that :)

My customer did that and he really feels bad

but he was only using it improperly on PV; otherwise his code would have exploded

so your extend-type is a scary but plausible workaround

you don't need (nor should you) extend to any other type

I would say there are mixed feelings around "vectors of exactly length 2" being map entries. kind of a kludge but also awfully useful. Ideally we'd have actual fixed length tuples and use a 2-tuple. Maybe someday.

@alexmiller I think the issue here is he is upgrading clojurescript, and clojurescript used to impl key and value on PV, but now doesn't because it introduced MapEntry

so he has a codebase that used to work and now doesn't

yeah, I get it

clojure has shifted a bit on this too

becuase he was accidentally using key and val on PV that were not of map-like provenance

It has? I don't remember key/val ever working on PV

(in clojure)

we went down the tuple path for a bit in 1.7(?) and I think there were some alpha/betas where that worked

@viebel it was always an implementation detail

and it never worked in Clojure

if your application depends on that detail then your protocol trick seems fine to me

alignment with Clojure on MapEntry has a bunch of benefits

conj still works with a 2-vec on maps

(in both Clojure and ClojureScript) - I guess that’s also convenience, expecting people to manually create MapEntries is also not very nice. On the other hand, you can use assoc.

and the previous behavior wasn't something that people were consistently relying on - and the number of complaints hasn't been that significant

@borkdude that doesn't seem that related

just to illustrate that there are still places where 2-vecs are used semantically to represent a MapEntry. same for printing map-entries: they are printed as 2-vecs (which sometimes leads to confusion)

I would probably argue differently I think in these cases

MapEntry should probably be considered an implementation detail fundamentally

so there isn't a real discrepancy here

the only issue is people treating 2 element vectors unrelated to maps

as things that support key and val

the other points just don't seem relevant to me

(though of course yes easy to see that all those points muddy the waters)

do you consider key and val implementation-level functions?

no but that's not in conflict with what I said above

"something you got out of a map"

right

so the breaking change is that some random vector responds to key and val

but of course fixing that unbroke other very basic things