Show Posts
1
Feature requests / Conversion of all SFML classes from using private to protected
« on: December 04, 2015, 07:16:29 am »
In regularly using SFML, I often encounter a class where I want to expand it's basic functionality (a term for this is extensibility), but I'm unable to do so as it's contents and functions are declared private, which means only members of that class and friend classes can access it.
A prime example would be adding pause functionality to the sf::Clock.
Often, the individual is faced with a choice: either write their own class from scratch to address what is usually only a few additional functional add-ons, or port the SFML source code, make modifications at the low-level and then compile a new library, which then often makes any code reliant on it incompatible with the active version of SFML (and thus requires all future additions of SFML be modified in the same way, a time consuming process!).
A very simple solution, which comes at no cost to SFML and greatly increases it's functionality, is for SFML classes to change their private contents and functions, to protected, which allows a subclass to inherit and access both the functions and the contents, which would allow people to readily extend SFML whilst solving problems such as allowing people to add pause functionality.
It might be argued that private is there as a form of protection, however, given the user is forced into implementing their own (dodgy!) design (either their own standalone class or modifying the library), it's safer if they're allowed to simply expand a pre-existing stable class.
For example, right now (ignoring the Pause example for sf::Clock) I'd love to implement my own append and get split channel style function for sf::Buffer, but it's looking like I will have to copy out sf::Buffer's contents, modify it, and then put it back in, which is pretty messy and would look neater as an expanded sub-class of sf::Buffer, but without direct access to it's internalised vector, will require I declare duplicate space (a big overhead on large sound files) to do things like append operations - noting that std::vector directly supports appending (where I can simply 'attach on' a sound file without duplicating sf:Buffer's contents).
I know the idea of shifting it from private to protected will get stick from those in-favour of the status quo, but my classes in my library use protected de facto to allow extensibility *unless* I can justify the usage of private (IE a function call must only be called in specific states that only the class itself knows).
A prime example would be adding pause functionality to the sf::Clock.
Often, the individual is faced with a choice: either write their own class from scratch to address what is usually only a few additional functional add-ons, or port the SFML source code, make modifications at the low-level and then compile a new library, which then often makes any code reliant on it incompatible with the active version of SFML (and thus requires all future additions of SFML be modified in the same way, a time consuming process!).
A very simple solution, which comes at no cost to SFML and greatly increases it's functionality, is for SFML classes to change their private contents and functions, to protected, which allows a subclass to inherit and access both the functions and the contents, which would allow people to readily extend SFML whilst solving problems such as allowing people to add pause functionality.
It might be argued that private is there as a form of protection, however, given the user is forced into implementing their own (dodgy!) design (either their own standalone class or modifying the library), it's safer if they're allowed to simply expand a pre-existing stable class.
For example, right now (ignoring the Pause example for sf::Clock) I'd love to implement my own append and get split channel style function for sf::Buffer, but it's looking like I will have to copy out sf::Buffer's contents, modify it, and then put it back in, which is pretty messy and would look neater as an expanded sub-class of sf::Buffer, but without direct access to it's internalised vector, will require I declare duplicate space (a big overhead on large sound files) to do things like append operations - noting that std::vector directly supports appending (where I can simply 'attach on' a sound file without duplicating sf:Buffer's contents).
I know the idea of shifting it from private to protected will get stick from those in-favour of the status quo, but my classes in my library use protected de facto to allow extensibility *unless* I can justify the usage of private (IE a function call must only be called in specific states that only the class itself knows).