Before this descends into a gaping abyss, let's come up with the final API
The main controversy in this thread revolved around the appearance of a window in the API (which is needed by some, but not all platforms). Towards the end of the discussion, many arguments were in favor of an independent
sf::Clipboard class with static functions taking a window parameter:
class Clipboard
{
public:
static void copy(sf::Window& window, const sf::String& text);
static sf::String paste(sf::Window& window);
};
However, this is not ideal from an object-oriented and semantic perspective; it's neither intuitive nor handy to have a window around whenever the clipboard is used.
I have a new idea that would combine both requests (have a window in the API but without clutter). We essentially move away from the global access -- but keep in mind that was illusory, because you had to keep a window around. This API uses an instance-based (non-static method) approach:
class Clipboard
{
public:
void copy(const sf::String& text);
sf::String paste() const;
private:
sf::Window* m_window;
};
class Window
{
public:
Clipboard getClipboard(); // const?
};
This has several advantages over both a purely
sf::Window-based interface and a singleton-style
sf::Clipboard class:
- The interface is much simpler. The user need not specify the window all the time.
- We don't have a global class, thus resource lifetimes can be bound to the object, not the program duration (either sf::Clipboard, but probably more meaningful sf::Window).
- We can use const-correctness: if we want certain modules to only read but not write to the clipboard, we pass them a const-reference.
- A window is not strictly required: a platform can provide other means of creating sf::Clipboard instances.
What we can still discuss is whether
sf::Clipboard has value semantics, and every instance refers to the same clipboard; or whether we make it noncopyable and allow only to pass around pointers and references.
What do you think of this idea?
