Set an object's color without creating a color object

[Phanoo]

A small wish for me:

Allow to set color to sprites/shapes without having to create a Color object.

example:
Sprite s;
s.setColor(200,200,200,100);

instead of
s.setColor(Color(200,200,200,100));

same with the RectangleShape constructor. Set directly its size, without having to create a vector2f object:  RectangleShape rect(10,10) instead of RectangleShape rect(Vector2f(10,10))

The small things that makes life easier

I like SFML's Oriented Object style , but sometimes it's a bit too heavy

[Laurent]

Really? Is it going to change your life? Does it deserve that we create tons of overloads and make the API bigger than it should be?

Anyway... with C++11 support you'll be able to write something close to what you want:

s.setColor({200,200,200,100});

[Phanoo]

It just makes the code looks clearer, i think we need to have both like it's already the case for some methods (setPosition ? i'm not sure i can't verify now, but for some class i can pass either a Vector2f or two floats x and y)

[Ixrec]

Though I agree it's not worth adding these overloads solely for convenience (after all, there's a reason we're supposed to write out std:: and sf:: every single time), I think there might be a legitimate concern about consistency.  Looking just at sf::RectangleShape, we have:

- RectangleShape (const Vector2f &size=Vector2f(0, 0))

- void setSize (const Vector2f &size)

- void setTextureRect (const IntRect &rect)

- void setFillColor (const Color &color)

- void setOutlineColor (const Color &color)

- void setPosition (float x, float y)
- void setPosition (const Vector2f &position)

- void setScale (float factorX, float factorY)
- void setScale (const Vector2f &factors)

- void setOrigin (float x, float y)
- void setOrigin (const Vector2f &origin)

- void move (float offsetX, float offsetY)
- void move (const Vector2f &offset)

- void scale (float factorX, float factorY)
- void scale (const Vector2f &factor)

It does seem at least a little inconsistent that the constructor and the setSize methods don't have a two-floats overload when all the other methods taking a Vector2f do.

Maybe it's only worth changing this stuff for SFML 3 when sweeping changes to the APIs are possible, but we should probably aim to have a consistent rule about when "piecewise overloads" are available and when you have to go through a vocabulary type (even if C++11 makes it as simple as an extra pair of curly braces).

My first idea for such a rule: If the type has only one constructor taking scalars (like sf::Vector2f or sf::Color) and the method takes nothing but that type (so no risk of confusion) then provide a piecewise overload.  Alternatively, I'd probably accept the other extreme of removing all such overloads and instead requiring the extra {} every single time, assuming SFML 3 will in fact be C++11-only.

[binary1248]

Come SFML 3, we might drop the single component overloads for consistency, since as Laurent already showed, it becomes trivial to pass in the values using braces instead.

[Nexus]

The reason why this is not provided is combinatorial explosion: instead of having a constructor for a type once, you need to provide a separate overload everywhere the type is used as a parameter.

I'm also in favor of removing the component-wise overloads in SFML 3. It has the nice side effect of motivating people to use the classes as intended; for example I could imagine that it helps people understand the concept of vectors as an abstraction of separate X/Y coordinates.

[Jesper Juhl]

Given that it's trivial to just call the relevant functions with {x, y, z} in modern C++, I think the overloads should just go away.  Just my opinion.

[minirop]

Given that it's trivial to just call the relevant functions with {x, y, z} in modern C++, I think the overloads should just go away.  Just my opinion.

they probably will go away when SFML goes full C++11, not before.

[cob59]

Do you think a variadic template overload of setColor would be an overkill?

template<typename... Args>
void Sprite::setColor(Args... args) {
  this->setColor(Color(args));
}

[Laurent]

Yes.

The question is not how to write the overload, it is do we want the overload. And the answer is clear if you read this thread