sf::Color single values modifier

[barnack]

Greetings,
i wonder why single values of a color are not editable from the getter. I understand the "getColor()" method returns a constant to avoid deletion from memory. But then wouldn't it be viable to allow actively setting the values within that color?

If i only want to change something's "blue" component, why should i replace a color?
The only way i found till now was something like:

sprite.setColor(sprite.getColor().r, sprite.getColor().g, sprite.getColor().b + blue_variation, sprite.getColor().a + alpha_variation);
 

Wouldn't something like the following be more cpu-efficient, readable and clean?

sprite.getColor().setBlue(new_blue_value);
sprite.getColor().modifyBlue(blue_variation);
 

[Laurent]

setColor doesn't just assign the argument to an internal sf::Color variable, it also does some extra work, like assigning the new color to all the entity's vertices.

[barnack]

can't this be done by setting a single attribute as well? You'd still avoid the need to replace the entire sf::Color instance, plus definitely making it more readable.

[Laurent]

can't this be done by setting a single attribute as well?

Something like this?

sprite.setColorBlue(255);

Good luck for implementing the hundredth of similar setters that will be needed then, and the fat API that will result from that

Sprite::setPositionX
Sprite::setPositionY
Sprite::setOriginX
Sprite::setOriginY
Sprite::setScaleX
Sprite::setScaleY
Sprite::setColorRed
Sprite::setColorGreen
Sprite::setColorBlue
Sprite::setColorAlpha
...

Internally they would still end up calling the same setter that takes the whole color, because as I said, those setters often do much more than modifying a member variable.

If you really feel like writing those 3 simple lines is "less readable" than a single call, feel free to implement your own function on top of the existing setter.

auto color = sprite.getColor();
color.b = 255;
sprite.setColor(color);

[barnack]

Good luck for implementing the hundredth of similar setters that will be needed then, and the fat API that will result from that

Uhm, good point