Get- and Set-functions for a sfWindow.

[reven]

I find it quite weird that you choose to create a function "UseVerticalSync(bool)" and at the same time provide no functions for getting the boolean variable. I guess that there are other than me who would like BOTH get- and set functions for a window.

When creating a game, you'd most likely want to implement some kind of console which can set and get the variables. That is quite easy to do with delegates and boost::bind, but having to implement you own set and get methods for each variable, just for use when recreating the window is a bit silly.

You can get the window width, but you cant set it. There's no way of actually modifying the variable itself, so i cant write my own Set-functions, and therefor I cannot bind such functions in a console system. Same goes for height, bits per pixel, window caption etc. And the opposite is the case for UseVerticalSync.

And now that we are at it. Why even call the methods "Get<thing>".  In C++ you can use overloading to do like this instead:

Code: [Select]

void Width(const unsigned int)
{
< " assign "> ;
}
unsigned int Width() const
{  
< " return " >;
}

[Laurent]

I really don't like putting hundreds of accessors in a class. I design my classes so that they implement useful behaviors, not as a set of states that you can read / write. If you need to keep track of such states just use additional variables

I'll add some functions to be able to move the window and things like this, but I won't provide a full set of window-related functions, as it's clearly not the goal of SFML. I you want to be able to play with your window after you create it, then rather use Qt or wxWidgets and embed an SFML view into it.

I really want to keep the public interface of SFML clear and simple, and not bloat it with a lot of functions for reading / writing each possible state of each class.

[reven]

You already provide tons of getters. With the proposed way of operator overloading the interface is just as clean, in my opinion.