Clojurians Log v2

@dominicm the problem is that's only true for modern JS environments - if you think about back when this was done this was to prevent bad code gen - stuff that couldn't be loaded

and this is still true when you target stranger or older environments

@dnolen in that case this feels separate from es5 or not, and is to do with some other aspect of the environment. It's possible to have an es3 environment with a method named x.delete.

In any environment, if you use an interop form it should do exactly as I say. The language in/out doesn't matter.

so delete is really a weird special case

No. All reserved keywords can be used as x.reserved

The spec is unambiguous on this

I will say I do not remember this being true having hacked on JS since IE6

foo.class etc.

you're saying this is present in the ECMAScript spec from 2001?

I will double check for you, but I think so

@dnolen there is no ECMA-262 for 2001. There's 2011 and 1999 (and 2009 in the middle). Which did you mean?

https://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%203rd%20edition,%20December%201999.pdf

pretty sure the reserved words are reserved in a hard way - including properties

however I agree it's 20 years later and it's pretty rare to run into a JS runtime now that has this problem

Okay. You're right :) In 3rd edition it was an identifier. I should be more careful. So from ES5+ all reserved keywords are available as property names (which I will now verify too!)

ok cool

(11.2.1 "Property Accessors" in the 3ed uses "Identifier", which cannot be a reserved name)

so ... I think your idea is still fine, I think we can make this work in the dot property emission part of the compiler

I think you can just check to see if reserved, if so and the language setting is ok, skip munging

The number of finals in the title of 5ed 2009 ECMA-262 is... concerning.

@dnolen yeah, we already have the es5-whitelist or something, I think any places that use that need changing.

Unless I miunderstand the purpose of having the es5-allowed for "default"?

Why doesn't the compiler emit x['class']()? Is that also newer syntax?

https://clojure.atlassian.net/browse/CLJS-3247 created ticket & uploaded patch. No tests, but happy to write them. Will need a little guidance on how & placement.

great thanks, I'll have to take a look later - looking into other regression tickets today

No rush :). Playing around with this ticket I noted that ((.-delete window)) seems to work... so if I can get externs inference to play nice with that I'll be golden. I can't update until figwheel-main is updated anyway.

I noticed with Reagent node module processing test suite that 753 doesn't work with default language-out, but works with :es5. Any idea idea if this is something already known or expected? Problem is with $jscomp name, which I think is from Closure polyfills for Object methods used by object-assign. (In this case the es3 output is 8KB vs 3KB for es5 output due to polyfills.)

Or the name might be ok, but a file that initializes $jscomp object is missing.

my understanding is that $jscomp appears if language out is wrong

Closure has the name written like that: https://github.com/google/closure-compiler/blob/3aaf3475128e8f7e398a42b3400256aee4870bbe/src/com/google/javascript/jscomp/js/util/polyfill.js#L26 so doesn't seem like problem with munging

@juhoteperi my understanding is that it's expected, certainly not new?

when I tried to compile React earlier - I had to set language out

This worked in 597

when I say not new I mean this seems unrelated to ClojureScript releases

Probably caused by Closure compiler update

yes

I'll just set language-out to es5. Doesn't seem important enough to investigate why es3 doesn't work.

@mfikes hrm does the compiler inline protocol fns or something?

@mfikes I realizing this is probably why https://clojure.atlassian.net/browse/CLJS-3244#icft=CLJS-3244 is so strange

all the line numbers are off

and they appear in a file w/o any imports

this would only happen if something was being inlined from a different ns

Might be related to the recent "protocol static dispatch inlining"... let me find that commit

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

^ this was really about just making it easier for runtimes to inline stuff, that's all

FWIW, I tried an experiment reverting CLJS-3185 and the problem persists (and the line numbers are still off), so maybe CLJS-3185 is unrelated.

I wonder if this is because of the type hints

though that also seems strnage

ok yes

@mfikes actually the line numbers are fine

not used to all this type inference stuff working 😛

anyways, somewhere we're trying to resolve type hints and that's going wrong - will look into that now

@mfikes the inlining stuff definitely is completely unrelated sorry for the bother