My vote explained: methods that return Object for no apparent reasons just makes me sad.
1 Like
Methods that return a type for no apparent reason make me sad, too.
To me it’s the same as a method that returns ArrayList when List will do.
The return type should be based on usage. The only user of jmeClone() is the cloner… which only needs object.
2 Likes
Clearer to whom?
Clearer to the person who maintains the code in question.
Yeah, that’s the part I don’t understand.
If you are reading the code in the method then you can clearly see what it’s returning.
If you are reading the outside of the method then the return type doesn’t matter.
And if you don’t understand what jmeClone() is doing then don’t touch a single line of it until you’ve read the JmeCloneable javadoc and have a clear understanding of what it’s doing.
But if you guys really want to change a method signature and potentially break user code because “this is a little strange to me but otherwise doesn’t matter”… then knock yourself out. Code quality and confusion be damned.
Edit: but if even ONE user sees that return type and calls jmeClone() directly then you have utterly failed in your mission of clarity.
2 Likes
I’m glad we’re having this discussion. Apparently, you and I “read code” in a very different manner. Which is good to know.
So in the case of:
public class Foo {
private ArrayList bar = new ArrayList<>();
public ??? getBar() {
return bar;
}
}
What return type would you use?
2 Likes
99% of the time, I wouldn’t write it that way to begin with. I’d write:
public class Foo {
private List bar = new ArrayList<>();
public ??? getBar() {
return bar;
}
}
and add javadoc to indicate what getBar() and Foo are supposed to do.
in which case, ??? becomes List.
I can’t imagine any circumstance under which ??? would become Object. That would seem unnecessarily coy.
1 Like
And if I knew the type of object in the ArrayList, I’d specify that, too, of course.
The class might need some specific thing to do with ArrayList which is why it keeps it fully typed internally but you will still likely return List.
Because the return type is based on what the caller needs to see. As both implementer of the method and user of the method, I need to be aware of this… and if I’m reading an implementation that returns ArrayList then I’m going to assume the caller also needed something specific about ArrayList.
If I’m looking at the modified jmeClone() implementation, here is what goes through my head:
(1) Ah, this method is cloning the object.
(2) and it’s just returning it… what type does the caller see.
(3) Ah, user code must be calling this to get a clone of this object.
Versus:
(1) Ah, this is cloning the object…
(2) and just returning it
(3) Oh, and callers must not need to know the type at all, this is probably not user callable code… what does the javadoc say…
The first way is dangerously wrong.
Edit: and here’s another way one can look at it… jmeClone() is not returning a fully created AnimComposer above. It’s returning the egg of an AnimComposer that only fully hatches once taken through the full cloning process. No regular caller should ever use that object directly and the Object return type signifies this. Technically, we could return any object we wanted here if the cloner was setup to deal with it.
1 Like
You read code in a bottom-up fashion. I read it in a top-down fashion.
1 Like
I have to ask for something here, if a user who is drunk for some reason has implemented JmeClonable & found out that jmeClone method returns Object, but at the same moment he is still overriding the AnimComposer jmeClone() for his superclass(), would that make him confuse …?
I think that would make a great confusion, if he don’t know about this conversation 
.
If the 2 the methods have the same signature, the application wonot compile…otherwise it will, but which method will JmeClonable use 
EDIT : Oh, I forgot that overloading is done only if parameters number & type argument are different…
If I want to know what a method is doing then I read the method. If I want to know how a method is used then I read the signature.
The method signature is how the method is used. The method body is what the method does. You indicated that you were confused about what the method is doing based on the return type… but if you are already looking at the method then the body will tell you exactly what it’s doing.
There are also a lot of other subtle clues in that code that the careful reader can make assumptions about.
So is that negating the entire point of your post or only part of it? Users are free to return whatever they like and create whatever headaches they want for themselves.
JME should opt for clarity no matter whether you are reading the body of the method or using code completion and scrolling through all of the things you can do on an object… or are just reading the javadoc method list.
And there is no requirement that jmeClone() needs to even return the same type of object. That’s all up to how the cloner is implemented. One needs to have a basic understanding of what the Cloner is doing before going too far out of what’s already written.
Thanks for all the input.