[CLJ-1249] Warning when a record field with the same name as a function exists for it Created: 26/Aug/13 Updated: 31/Jan/14 Resolved: 31/Jan/14
|Affects Version/s:||Release 1.4, Release 1.5|
Linux, clojure jar or leiningen repl
I had the following problem which took me much longer than it should have. I accidentally had a record's field with the same name as one of the functions from a protocol. When I tried to call the function from within the record I got totally weird behavior and didn't find it, until I removed every piece of code when I found the name conflict.
I wish clojure would warn me in such a case. (Disregarding any naming conventions that could have saved me.)
Following a small example to reproduce the problem:
Warning: the protocol function "dog" from "HasPets" conflicts with the equally named record field of "Petshop"
Without dog as a record's field:
Thanks for your help.
|Comment by Alex Miller [ 26/Aug/13 1:20 PM ]|
Thanks for the report.
It seems like there is a scoping issue here where dogs is bound to the field and there is also a context for it being referred to as a function. It's possible that this should really be treated as a compiler bug and not a warning message problem - that requires some more detective work. Since there is only one function dogs (the field name is a function only in keyword form - :dogs), it seems unambiguous what should be done here.
In the meanwhile, presumably a workaround would be to use extend-protocol, etc to attach the protocol to the record outside the record definition.
|Comment by Gary Fredericks [ 09/Dec/13 8:24 AM ]|
Alex I can't see a lack of ambiguity here. I read your comment as saying that because dogs is in the call position we can deduce that it's meant to refer to the function rather than the field. But we can't assume that a field is not an IFn or intended to be used as one, so I can't make sense of that.
Another workaround should be using a fully qualified reference to the protocol function.
My expectation as a user of defrecord and deftype has always been that ambiguous references always refer to the fields, as if there were a let around each function body. So I've done this kind of thing intentionally I think. I don't know what that means about whether or not it should be a warning.
Should warnings for this kind of thing be accompanied by a way to suppress individual instances of the warning? E.g., a ^:no-warn metadata somewhere?
|Comment by Stuart Halloway [ 31/Jan/14 2:41 PM ]|
It is correct and legal code to have a record or type field shadow a var name, and as Gary mentions, the var is still reachable via a qualified name.
This might be a good warning for a linter like https://github.com/jonase/eastwood, if it is not present already.
|Comment by Andy Fingerhut [ 31/Jan/14 2:55 PM ]|
The Eastwood linter currently has no warning for this situation, but I have created an issue on its Github page to record the enhancement idea: https://github.com/jonase/eastwood/issues/55
|Comment by Benjamin Peter [ 31/Jan/14 3:26 PM ]|
Okay, thanks guys.