This stuff is cool, but difficult to use.
I'm trying to embed the game canvas within a Swing environment. I'm making some progress but it is quite slow as I don't know the class structures to use. I've browsed this forum and seen suggestions to use the RenControlEditor.java code as an example. I'm working through that slowly, but to understand more about how it works means digging into other classes.
The main reason it is slow going is because some of these classes don't have any basic information as to what they should do, nor how they should be used. I will, if it will help, over time post suggested comments to go into these, but I would urge you to add at the very least an outline comment at the top of the class to say what it does. Every public method in my opinion should have documentation to say why it exists, and the more the better.
Now on to my question.
Can someone tell me why com.jmex.awt.SimpleCanvasImpl has its fields as protected? I can't get access to the rootNode field for this reason. I've noticed in other classes that fields are made public. This would be an ideal case for getRootNode() and setRootNode().
This is another gripe (sorry!). Is this wise? It is good practise to hide fields from the outside by wrapping within getters and setters. This way you can safely change the internal implementation if you wish without affecting the interface. Public fields are there forever.
You're supposed to extend it, like you would extend eg. SimpleGame. RenParticleEditor is a good example. It's common to use protected fields in that case (it's like an abstract class).
Public fields are faster than getter/setter methods, so they are used in places where speed is important. Also it's not always a bad practise to expose fields as public. The jME math package (eg. the Vector* classes) are a good example of where aside from speed, by design it is (imho) a better choice. It certainly makes life easier for a programmer, and I don't see a good reason to wrap them.
Thanks for that. I appreciate the feedback. But doesn't this reinforce what I'm saying about comments? If you're supposed to extend it shouldn't that be the suggestion. If the class has already been extended to give it the flexibility needed that should be it – the class is available as a resource to be used, and so can be instantiated with the new operator rather than subclassed.
As for the Vector classes I can't ever see those being modified as they are so simple. But that rule doesn't apply to more complex classes where, in my opinion, you're potentially shooting yourself in the foot.
In any case I've no intention of making a big issue out of this. As I said, I appreciate the feedback and the chance to hear your point of view.
Cheers!
Yeah… it could use a bit better documentation. If I remember correctly, it was added because it was much requested… and within jME the "extend the Simple* class" is a well known (and documented in tutorials and such) way of working. The tests (JMESwingTest in this case) should also be seen as mini tutorials. But if you can write some good (java)doc enhancments, for either the class or the testcase, they're more than welcome.
As for the getter/setter issue, do you have any specific examples where you think it's not justified to use a public field?
Ta. I'm still trying to familiarise myself with the environment – code user doc and examples. As I see fit I'll make suggestions for the documentation to include (then it can be ignored or incorporated as appropriate).
As to where getter/setter methods could be used I'll try to point those out as I come across them. I've had a very busy day today and am absolutely knackered; I've forgotten where I saw them! Ill let you know over the coming days and weeks as I get up to speed with the system.
