[JOODE] public fields

Game Mechanics
#1

@tom: I saw, that you reverted my changes in Geom, Body, World, etc. about the public->private fields. Why did you do that? Don’t get me wrong. It’s your library and you have any right to do so. I just don’t understand, why you did that. Isn’t this JOODE? Which means to be object oriented? And good object oriented design means to have no public fields, but everything through getters/setters. And since all the new getters and setters are final, there is no performance loss, since they will all be inlined by the JIT compiler. Another advantage is, that you can clearly say, what is to do, when a field is accessed and you CAN do something at that time. And you can better navigate in Eclipse when getters/setters are used.

And why did you revert my clanup in EulerStepper?

Cheers,
Marvin

#2

Oh, apologies about the revert of Euler stepper. I shall rollback that back to the original tommorrow. I got confused when my version merged, I thought I had gone for the latest JOODE respository version but obviously not.

The reason I got rid of the private feilds was because EulerStepper was not compiling :confused: Obviously that was really becuase of the reason outlined above.

Personally I do not think public feilds are such a bad thing, they make alot of the codebase more compact. However, I certainly do not like to overwrite your valuable effert, and I know that private feilds are more traditional. So yeah, in summery I will rollback to before my changes today and just keep my modifications to the XithManager.

Sorry Marvin, a mistake on my part.

#3

Good to know. And thanks for replying.

Marvin

#4

Oh, btw. Will you replace the XithBindingsManager usage in the testcases with your new XithManager some day?

#5

I actually had performance hits with final modifiers (although they were slightly larger than getter/setter methods). See this post: http://www.java-gaming.org/forums/index.php?topic=17784.0

#6

Final will NEVER hurt. If the JIT Compiler is capable of inlining the code without the final modifier, then the execution speed will be exactly the same. And if it needs the final modifier to decide to inline, then the final version is faster. But it will never be slower. Believe me. I have run a lot of testcases for vecmath2 to benchmark that some months ago.

About the testcase posted in the quoted thread: I would expect the “slightly slower” difference to disappear when the two code blocks in the main method were flipped. This can make a difference. But doesn’t tell you anything about the “real-life”, e.g. about your real project.

And I am using the final modifier both as optimization hint and as “API feature” to disallow certain methods from being overridden.

Marvin

#7

OK rolled back.

XithBindingManager removed (and phew, that was alot bigger refactor than expected)

#8

Thanks.

Great work. Finally some less warnings ;). Thanks.

Marvin