SFML community forums
Bindings - other languages => Java => Topic started by: pdinklag on October 07, 2012, 09:40:37 am
-
I just pushed a re-designed mapping of SFML "const" references.
Java doesn't know const, which is one of the biggest drawbacks of the language, in my opinion. However, I had to find a way to map SFML's const references properly to assure that a default view of a window, to name one example, will not be modified by the user.
Let's stay with the example of the View class for now.
sf::RenderWindow provides a method to get the window's default view. The returned reference is const. In order to map this behaviour to Java, I introduced the interface called "ConstView", which provides only reading methods of the View class. The View class implements this interface, so the functionality is directly delegated to the original sf::View and no further implementation is needed.
I believe this is the best way to simulate const in Java. It is transparent to the user (unlike what I did until now) and also type-safe.
Now, with the knowledge that a "ConstView" is simply a View, you could trick Java and simply cast it to a View or, even more evil, use reflection. In the documentation, I explicitly stated that this should not be done. For critical cases, such as the default view of a window or the target texture of a render texture, I implemented an (invisible) subclass of the View class that will throw an exception if a write-method is being invoked. This is not a problem, because this can only happen if the user used one of the said tricks.
I'm not sure if this protection is really necessary. I imply that there will be people who intentionally work around the API restrictions using (simple) tricks and try to protect the API from that. Should I do this, or is a warning in the documentation enough?
-
In C++, I usually try to prevent accidental mistakes (mostly with assert), but not intentional abuses (it's not 100% possible anyway). There is always a way to break the library, I don't think it's worth putting a lot of effort into something of which the rational user won't benefit.
As an alternative to the immutable class, you could return a copy of the view in getDefaultView().
-
it's not 100% possible anyway). There is always a way to break the library, I don't think it's worth putting a lot of effort into something of which the rational user won't benefit.
OK, thanks for the heads-up.
As an alternative to the immutable class, you could return a copy of the view in getDefaultView().
The reason I prefer a read-only interface is because they can be implemented by the original object, no need to duplicate resources. For a view, it wouldn't be much, but if you get the target texture from a RenderTexture, for example, that would be too heavy I suppose.