The resources names will be removed, which will require some refactoring in the Image class.
The Image class uses constructor delegation that relies on an overload taking a resource name and a raw data string. The resource name parameter will need to be removed. However removing the resource name parameter will leave only the data parameter, which will make that overload ambiguous with the overload taking only a filename. In that case, both overloads have a single parameter and both are of the same type (std::string).
The future ambiguity of the file and data constructor overloads needs to be resolved. There is no obvious alternative parameter type to use, nor any obvious other parameters to add to resolve the ambiguity. This leaves the option of removing one of the constructor overloads to resolve that ambiguity. Perhaps a factory function can be used to replace that functionality, so the factory function name can be used to resolve that ambiguity while maintaining functionality. Meanwhile though, we need to unlink the constructor delegation so one of the overloads can be removed. Currently the resource caching code relies on the overload taking a filename, while no code relies on the overload taking a data string. The obvious choice will be to remove the overload taking a data string.
In preparation for removing the Image constructor overload taking a data string, we need to re-work the overload taking a file path so it no longer delegates to the overload taking a data string. It makes sense to rework some of the other related constructor code as well, so everything is consistent.
Prep work for:
The resources names will be removed, which will require some refactoring in the
Imageclass.The
Imageclass uses constructor delegation that relies on an overload taking a resource name and a raw data string. The resource name parameter will need to be removed. However removing the resource name parameter will leave only the data parameter, which will make that overload ambiguous with the overload taking only a filename. In that case, both overloads have a single parameter and both are of the same type (std::string).The future ambiguity of the file and data constructor overloads needs to be resolved. There is no obvious alternative parameter type to use, nor any obvious other parameters to add to resolve the ambiguity. This leaves the option of removing one of the constructor overloads to resolve that ambiguity. Perhaps a factory function can be used to replace that functionality, so the factory function name can be used to resolve that ambiguity while maintaining functionality. Meanwhile though, we need to unlink the constructor delegation so one of the overloads can be removed. Currently the resource caching code relies on the overload taking a filename, while no code relies on the overload taking a data string. The obvious choice will be to remove the overload taking a data string.
In preparation for removing the
Imageconstructor overload taking a data string, we need to re-work the overload taking a file path so it no longer delegates to the overload taking a data string. It makes sense to rework some of the other related constructor code as well, so everything is consistent.