I’ve noticed many places in the Engine where jmeClone() methods specify Object as their return type. I understand why this was done in “JmeCloneable.java”. However, I don’t see why it should be the case in any other class.
For instance, wouldn’t it be clearer to have (in “AnimComposer.java”)
Not sure if I am mistaking this, but you can’t change the return type for @Overriden methods, so you’d loose the interface support, which I guess is the whole reason the return type is flawed, both here and in the jdk Clonable
But then they should be casting it to themselves and it doesn’t matter what they return. The pattern is the same for Java’s regular clone() method.
The issue I have with changing it is that it makes it easier to call it directly… which is already wrong. And the only “correct” reason to do it also isn’t correct since subclasses should be casting the result to themselves (or not at all if they don’t care).
It’s always better to favor abstraction over concretion…unless applying restrictions (more strict than some annotations requiring fields from the same package), but as you have said that returning a subclass of the proposed interface function would not break the overriding, but we may refractor 2/3 of jme classes .
I think this depends, if the user has implemented JmeClonable interface & used super.jmeClone() inside to get the default code then add his own code without overriding the method jmeclone directly, there would be no breaks, otherwise if he overrides directly w/o jmeClone he may break the code if he returns Object because the super class now doesn’t use Object, it uses Object+AnimComposer code.
Reasons not to do it: it provides no benefit, makes it seem like this is a method that users should be calling, will confuse anyone trying to reason about what this method is for, might break existing code.
Show me one good example of where this would be helpful to anyone… so I can correct you on usage.
I believe it would help someone reading the existing code, as in the “AnimComposer.java” example I posted at the start of this discussion. It would make it clearer what type of object the function returns.
Clearer to whom? The coder that shouldn’t be calling it or the coder that shouldn’t be calling it… or the coder that shouldn’t be calling it. No user code should ever call this method. If it were possible in Java then it would be private.
The super.jmeClone() argument isn’t a valid one because the caller should already be casting it to the local class and it makes no difference what it returns.
For everyone else, returning a real type only makes it look more like a method that code should actually be calling.
The fact that we are even having this conversation is only proving to me how much more confusing this method would be if it returned a real type… because somehow folks think it matters. Which seems like a clear misunderstanding of the method to me.
Anyone writing their own jmeClone() method will need to spend a few minutes understanding what it does and why or they will do it wrong.
I think may be you can document the jmeClone() interface method with this option & let the user choose what he/she wants to do, so if he wants to keep it abstract so be it, otherwise he stills have the option to return a concrete subtype of the extended instance …may be…it won’t matter very much, but I am just giving out an option…