clojurescript 2022-06-08

pinkfrog09:06:01

Given the code here: https://github.com/clojure/clojurescript/blob/b236032061bc3c68c18adab4e5bcc3e47404d65c/src/main/clojure/cljs/core.cljc#L2697, does that mean I can use (alenght x) to call anything x that can be called with x.length() ?

thheller09:06:02

x.length not x.length(). its a property, not a function call. technically the a* functions are meant for arrays and there are some warnings when used on something not an array

thheller09:06:08

but yes, technically you can

pez16:06:14

Why does this throw?

(str/replace "// foo" #"(\/\/).*" "") => Execution error (SyntaxError) at (<cljs repl>:1). Invalid regular expression flags

The regex works in JS:

"// foo".replace(/(\/\/).*/, "") => ''

pez16:06:01

It's not in my code, so I don't know why the slashes are escaped.

pez16:06:34

It works without throwing in Clojure, btw.

Max16:06:45

it works fine for me in a CLJS repl here: https://clojurescript.io/

Max16:06:51

as a data point

p-himik16:06:50

During regular compilation, for some reason those \ get escaped once more. Then that RegEx string gets embedded in /.../ as a JS RegEx literal - and those / you had there originally are now treated as boundaries of the JS RegEx literal. Why that escaping happens in the first place, I do not know.

pez17:06:50

Thanks @U2FRKM4TW! Makes sense. I'm cooking a PR converting a Clojure library to cljc, and ran into this. I've removed the escaping, for now, as I can't see why they would be needed. But I might find out once I file the PR. 😃

pez17:06:08

Very interesting that it works there, @UEJUEMGHF! I am curious as to what different paths the reading takes.

Max17:06:30

Me too!

William LaFrance16:06:39

(i'm super new to clojure and possibly wrong but) is escaping with \ necessary in a clojure regex?

pez16:06:58

I don't think so. This is not my code, so I don't know why they are escaped. It works fine in Clojure, btw.

simongray09:06:45

it isn’t necessary, no. Only when you need to escape regex characters themselves, e.g. \. to represent a dot.

Quentin Le Guennec20:06:32

Hello, is this expected to work: • set! a object method m with a new function • pass this object to a javascript library that is excpected to call m • the library in question will call the function overriden with set!, not the original one

p-himik20:06:22

Yes.

Quentin Le Guennec20:06:44

Are you sure?

Quentin Le Guennec20:06:12

From what I understand about this answer it shouldn't: https://clojurians.slack.com/archives/C03S1L9DN/p1652707760445009?thread_ts=1652454308.301139&cid=C03S1L9DN

p-himik21:06:50

Well, that's a different question altogether. Your question in this thread talks about a JS object and a known field name. And if it's fed to a third-party library, that field name would be in the externs. Your question in the linked thread is about modifying CLJS objects where names could be minified and where you would rely on the exact way things are munged.

Quentin Le Guennec21:06:39

Oh yeah I understand.

Quentin Le Guennec21:06:06

Okay so the issue should me on my side then, I will double check my code

2022-06-08

Channels