With the presence of the record definition, the macro expander seems to expand
(.getBytes ^String x) into (. ^Class (clojure.core/identity ^java.lang.String x) getBytes) and which causes reflection call. (BTW this "tricky" expansion is done to distinguish instance method calls on Class objects from static method calls if I understand correctly. cf. https://github.com/clojure/clojure/blob/653b8465845a78ef7543e0a250078eea2d56b659/src/jvm/clojure/lang/Compiler.java#L7035-L7039) So, to resolve the issue, I think the macro expander should look at the local env first to check whether or not a local binding shadows the class-ish name. On Thursday, August 29, 2019 at 8:08:32 AM UTC+9, Brian Craft wrote: > > In this example > > (defrecord x [y]) > > (defn b [x] (.getBytes ^String x)) > > > The compiler fails to resolve .getBytes. It emits reflection code, saying > x is a class. It is resolved by deleting the defrecord, or renaming the > parameter. > > Is this expected, or documented? Are there other cases like this? > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/5f9cd850-900f-442f-961a-98d1c67f3444%40googlegroups.com.
