Yes, I understand that storing a reference is "bad" design, because you can incur in a lot of problem. I never meant that. But what I really meant is: why not store the sf::View within the classes that needs it (for example sf::RenderWindow), as I believe is right now, and be able to return a reference to it that is not constant.
Here's an example:
namespace sf {
class RenderWindow {
private:
View m_view;
public:
// ...
View& getView(); // this is key point here, this is the function I'd like
const View& getView() const; // this already exists
};
};
If sf::RenderWindow stores a copy (as apparently it does) why not allow to modify that copy? The above design is constant correct and avoid the creation of a new sf::View every time you have to really modify the current one.
By the way, performance is definitely not a concern here, and thus not a relevant factor for the design.
I agree that the performance loss of copying a sf::View in most cases can be ignored. But if you have a clean way to do something better, don't you do it just because it is not a relevant factor perfomance-wise?
Just to be devil's advocate for a moment:
We could always add this method:
void sf::RenderWindow::setView (const FloatRect &rectangle) {
sf::View v(rectangle);
setView(v);
}
Seems like it would make him happy (lets you change the view in one line) while preserving all the Good Things about the current interface (only mutate through mutators, etc). Though it's such a minor thing I'm not sure I personally care either way.