Clojurians
#cljs-dev
<
2016-06-11
>

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

mfikes15:06:16

I’m surprised Closure would do this: https://github.com/google/closure-library/commit/bf758d3c2ef81b91e7d73608f68ee3c327b709d4 A consequence is that any ClojureScript code requiring goog.array.ArrayLike will break with the next ClojureScript release. (Dunno if that’s actually important, but the principle of the matter seems important.)

mfikes15:06:45

Here’s another one. I suppose there’s just a mentality that doesn’t match my expectations (which I’ll revise): https://github.com/google/closure-library/commit/756182c7c566898ba0847d80b0c87389f7c037b6

dnolen17:06:41

@mfikes: they change the compiler and the library quite a bit, there’s not much we can do about it

mfikes17:06:55

Yeah. I’m accustomed to the Java platform model of striving to never break anything. I like the recent rant Rich is on about changing names.

potetm21:06:39

Is it a known issue that in nashorn: before loading a namespace typeof my.existing.namespace.my_deffed_var => "object"?

potetm21:06:11

This affects the behavior of defonce.

potetm21:06:41

I looked in jira but couldn't find anything. Thought I would check here before filing an issue.

potetm21:06:56

Well, this happens at the REPL at least.

dnolen21:06:57

@potetm: not known, we don’t have many people using Nashorn yet

potetm21:06:33

Yeah, I figured it was one of the lesser-used parts. The only reason I'm looking into it at all is I'm playing with a library project and was curious about portability.

potetm21:06:44

I'll file a report in JIRA today or tomorrow.