Issue defining a defrecord protocol method named "clear"
There seems to be a problem in trying to define a protocol with a method named "clear"
(defrecord Foo 
(clear [o] o))
=> CompilerException java.lang.ClassFormatError: Duplicate method name&signature in class file xxxx/Foo, compilingNO_SOURCE_PATH:1:1)
I assume this is due to a name conflict with the Java method Collection.clear() in the underlying implementation. However the error is very unclear about this, and the potential for conflict appears to be undocumented as far as I can see.
There seem to be two possible approaches to fixing this:
a) Disallow the use of "clear" as a protocol method name (in which case the error should be more informative, and the rule should be documented)
b) Find a way to support this in the class file format (possibly by overloading on JVM return types, since Collection.clear() returns void??)
Ah, yes of course, thanks.
@Nicola Mometto : I believe the JVM does in fact support return type overloading:
"Note that there may be more than one matching method in a class because while the Java language forbids a class to declare multiple methods with the same signature but different return types, the Java virtual machine does not. This increased flexibility in the virtual machine can be used to implement various language features. For example, covariant returns can be implemented with bridge methods; the bridge method and the method being overridden would have the same signature but different return types."
It might be out of the scope of this ticket, but protocol method conflicts can cause some other kinds of errors:
IMHO it would be nicer if defprotocol would warn method conflicts with a more informative message.
I think this should be a doc enhancement request.
Mike, the jvm doesn't support return type overloading so your second suggestion is not technically possible.
Reading the doc for defrecord
The class will have implementations of several (clojure.lang)
interfaces generated automatically: IObj (metadata support) and
IPersistentMap, and all of their superinterfaces.
Perharps java.util.Collection (or even better, java.util.Map) should be mentioned here.