It’s not the ideas… it’s the delivery. There would be a way to make this constructive but you chose not to. You walked in, trashed everything, attempt to push style as substance in some cases, etc… Rather than ask why something is the way it is, you imply we are all stupid and everything is broken… because you didn’t get it or it’s not the way YOU would do it.
…which is fine. Somewhere out there is an engine for you. You should really try Unity and I’m not sure why you aren’t using it yet. It seems to be the standard you are holding us to.
To software engineers, making a method protected implies certain things. It implies that it’s a designed API to subclasses… either to be overridden or to be called. Furthermore, non-final public and protected methods will not be automatically inlined. Private methods are generally automatically inlined. There are good reasons to use private, protected, and public. Very specific reasons.
We are developing a framework that lots of users will use and try to understand. Peppering protected methods everywhere does not help that.
“Overriding this method so I can fix a bug” is both not a good reason to make something protected and is not really helping us in the end… because we’d like to actually fix the bug.
As to your examples, sometimes there is a specific (in JME’s case, often performance-related) case to break out of ‘good patterns’. Public fields in things like Vector3f and ColorRGBA is one of those cases. We sometimes pay the bad-engineering-practice price for this but we reap the rewards every day of not having to go through the extra indirection of a method call just to access them.
Networking is another specific case where we even override Java’s normal protections to directly set fields in the interest of performance. Setting a field directly is faster than calling a setter. Moreover it allows those classes to have otherwise private fields, ie: without even having setters. Serialization is almost always a case where it’s better to ‘break out’ of normal good practices. Even Java does it for its own serialization.
I don’t like nifty as much as you don’t like JME… so you’ll get no argument from me if you want to pick on nifty all day long. Some like it, though… and I’m careful not to imply they are stupid for using it when I criticize it. I try anyway.
Sure. It’s a nice type-safe way of grabbing a specific object from a bag of probably-typed objects. But this is a completely separate issue as compared to public versus private.
I’m the primary motivator for making the engine more pluggable. It’s been my goal since the beginning. We are nowhere near where I’d like to be and that’s a much longer conversation. (Why fixed buckets? Why fixed vertex buffer types? etc. It was easy at the time and now hard to fix without several rounds of phased changes to give users a migration path.) This is completely orthogonal to whether some method should be private or protected. Designing proper protected methods is harder. Doing it willy-nilly is dangerous.
To be honest, and to be fair to you, I did not remember which specific even pissed you off and turned you sour to us. I just know it happened and that most interactions with you since that time seem to have been this sort of aggressive insult/ranting/etc. sessions…
To maintain a framework, we have a lot of competing concerns. These must weigh in with our own free time and needs… and hopefully longer term plans for where the architecture should go.
It seems that our own decisions, the speed at which we’re moving, or just our style or completely counter to anything you’d find useful or desirable to use. There seems to be no middle ground. We do everything wrong in your eyes. We’re all idiots, etc… So you should find somewhere else that makes you happier.
