INRIA / spoon

Spoon is a metaprogramming library to analyze and transform Java source code. :spoon: is made with :heart:, :beers: and :sparkles:. It parses source files to build a well-designed AST with powerful analysis and transformation API.

Home Page:http://spoon.gforge.inria.fr/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Bug]: rename Spoon clone methods to another name

hunterpayne opened this issue · comments

commented

Describe the bug

Since the clone method is "special" in Java, overriding it is a bad idea. One consequence of this is that in Scala, you can't call the clone methods because the Scala compiler assumes that clone is part of java.lang.Object. Please at least provide another name to call these methods if not just rename these methods completely. Even just something like spoonClone would be fine but if there is a better name that is good too, just as long as it isn't a "special" name in Java (i.e. defined in java.lang.Object, e.g. equals, hashCode, clone, etc).

Source code you are trying to analyze/transform

No response

Source code for your Spoon processing

No response

Actual output

No response

Expected output

No response

Spoon Version

All versions, I'm currently using 10.3.0

JVM Version

JDK 17

What operating system are you using?

Doesn't matter, your code is in Java.

Hi,

just renaming the method would be heavily breaking, something we try to avoid as much as possible.
It also looks like this limitation does not exist anymore in Scala 3.

One simple workaround for you would be to write a Java class like that:

import spoon.reflect.declaration.CtElement;
public final class ScalaCompatibility {

	public static <T extends CtElement> T copy(T original) {
		return (T) original.clone();
	}
}

Alternatively, reflections will work too, I guess.

Given this is rather a edge case, I think it makes more sense to solve that where needed instead of changing things in spoon itself.

commented

Yes, a second method would not break backwards compatibility. It would, however, clutter the root interface for every downstream consumer. As there are simple workarounds for Scala 2 users (e.g. a java bridge class as @SirYwell mentioned above or maybe an extension method through an implicit class), this tradeoff does not seem worth it to us currently. We are not aware of any other JVM language exhibiting this problem.

Do you have any specific reason in mind that would tip the scales over?

commented
commented

As a side note, it is a nice surprise that you seem to know Scala. Has it occurred to you how much Spoon would benefit from the selftype in Scala? It would make your code so much easier to write. The lack of self type seems to be a major challenge for your project.

Closing this as we won't make this change and there are alternatives given.