Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Const References  (Read 1390 times)

0 Members and 1 Guest are viewing this topic.

pdinklag

  • Sr. Member
  • ****
  • Posts: 330
  • JSFML Developer
    • View Profile
    • JSFML Website
Const References
« 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?
JSFML - The Java binding to SFML.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6193
  • Thor Developer
    • View Profile
    • Bromeon
Re: Const References
« Reply #1 on: October 07, 2012, 11:17:03 am »
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().
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book

pdinklag

  • Sr. Member
  • ****
  • Posts: 330
  • JSFML Developer
    • View Profile
    • JSFML Website
Re: Const References
« Reply #2 on: October 07, 2012, 03:44:55 pm »
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.

Quote
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.
JSFML - The Java binding to SFML.

 

anything