Const References

[pdinklag]

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?

[Nexus]

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().

[pdinklag]

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.