scalePosition();

[Doodlemeat]

Hello.

What if we could give sf::Transform a scalePosition() method. It could save a few more keytaps and I think it looks pretty neat?  It is not a big thing, but it really helps

mySprite->scalePosition(0.5, 1);
or
mySprite->scalePosition(sf::Vector(0.5, 1));

[eXpl0it3r]

And now to the explanation of what the function should actually do, would be kind of useful.

[Doodlemeat]

It would change the position of the transformable object.

sf::RectangleShape shape;
shape.setPosition(100, 100);

shape.scalePosition(0.5, 1);

// shape.position = 50, 100
 

I do not see any drawbacks of doing so, neither is it confusing I think. Altough, typing a few more characters can achieve this but hey, we are lazy

[Nexus]

I do not see any drawbacks of doing so

It clutters the API unnecessarily. Why not a scaleRotation() too?

I don't think that's an often needed functionality -- positions are mostly used as points (in absolute world coordinates) and not dimensions.

neither is it confusing I think.

It is obviously confusing because it includes both "scale" and "position" but only affects one of these properties. When even eXpl0it3r, a very experienced SFML user, asks what it can mean, what do you think that newcomers expect?

If that's really a function that you're missing, then write a global function for it. This functionality doesn't have to be part of the sf::Transformable class.

[therocode]

...but hey, we are lazy

Are we now?

[Doodlemeat]

Yes, the human race are lazy

But I totally agree with Nexus. But is there any easy way of extending any SFML class with some few methods that will be avaible anywhere where I type #include "SMFL/GFX/Sprite.hpp" ?

[Laurent]

But is there any easy way of extending any SFML class with some few methods that will be avaible anywhere where I type #include "SMFL/GFX/Sprite.hpp" ?

No, you have to write your extensions in your own header, and include it instead of the SFML one.