sf::Rect<> design question

[Nexus]

Hi,

Is there a special reason to store the coordinates of the right and lower edge inside the sf::Rect class template? In my opinion width and height might be more intuitive. For example, you could use unsigned types for both and wouldn't have to assure that the right/down coords are bigger than the left/top ones. Additionally, the (from my point of view) often used width and height can be accessed faster. I know, performance of a subtraction is not really relevant, but consider more complex classes being used as template-argument T. Offset would be easier to calculate, too, and the effort of changing raw literals of image subrects would shrink.

I know, changing the sf::Rect structure is not possible at all, since it would break most SFML code up to now. That's not very tragic, one can easily build wrapper classes or utility functions. Nevertheless, I am wondering what was the crucial point for this design choice.

[Laurent]

In my opinion width and height would be more intuitive

I don't think so. They would be more intuitive in the situations you have in mind, but I can give you as many examples in favor of the current way of handling coordinates. The fact is that you'll always find people unhappy about a design choice when more than one solution is available.

For example, you could use unsigned types for both and wouldn't have to assure that the right/down coords are bigger than the left/top ones

So the current method is more flexible, as it allows reverted rectangles
This is actually useful if you want to define a flipped sf::View, for example.

But to me the most relevant point is that with your solution, sf::Rect would store two kinds of coordinates: a position and a size. So to be perfectly right, it would have to use two template parameters. This is not obvious with primitive types such as int or float, but what if you use a more complex type T as you mentioned? T may not be able to represent both concepts.
With the current implementation, T is a "position" coordinates for all members, and that's it.

My conclusion is that you can easily write your own functions / classes to get a sf::Rect from whatever using a width and a height, so go ahead

[Nexus]

I don't think so. They would be more intuitive in the situations you have in mind, but I can give you as many examples in favor of the current way of handling coordinates. The fact is that you'll always find people unhappy about a design choice when more than one solution is available.

Yes, that was only my view. I am not aspiring any alteration, but rather trying to reproduce the choice of the current sf::Rect design. I am aware of the fact every decision makes some people happy and some not. If you have got some time, it would be nice to see some of the examples you mentioned.

So the current method is more flexible, as it allows reverted rectangles
This is actually useful if you want to define a flipped sf::View, for example.

Okay, that is a point I haven't thought of. But I don't guess a rect like this is used often, is it? In contrast to SubRects of Sprites, for example.

But to me the most relevant point is that with your solution, sf::Rect would store two kinds of coordinates: a position and a size. So to be perfectly right, it would have to use two template parameters. This is not obvious with primitive types such as int or float, but what if you use a more complex type T as you mentioned? T may not be able to represent both concepts.
With the current implementation, T is a "position" coordinates for all members, and that's it.

But by strictly following this argumentation, the member functions GetWidth() and GetHeight() should return a type other than T, namely a difference type. This is not the case at the moment. But to be honest, I can't imagine a graphical use of a sf::Rect where position and difference are not compatible to each other. I know the concept from other things like pointers or iterators, still I can't apply this on graphical rectangles. Maybe I have just got too few fantasy...

My conclusion is that you can easily write your own functions / classes to get a sf::Rect from whatever using a width and a height, so go ahead

As I wrote, that's not the problem. I am already partially doing it like this. It's more a theoretic discussion, I hope you don't mind wasting time for something that won't affect the SFML library.
(You can consider it a variation to feature and help requests )

[Nexus]

Hmm... It would be nice if someone could comment this topic. I'd also like to know what other users think about sf::Rect.

All opinions are welcome...

[Tank]

I like the current design. A rectangle is built of 4 points, therefore Left/Top/Right/Bottom seems to be perfect in my opinion.

What *could* be added are methods like SetHeight() and SetWidth() (as counterparts to GetHeight() and GetWidth()) that only change Right and Bottom. But I guess it's not really important, since you can easily archive that by adding values by yourself.

[Astrof]

I know at first I was confused by the four point scheme as opposed to the origin + width/height.  But to fix it all I did was add the width and height to the origin points anyway...

I guess it depends what previous library or language you come from.  

I also agree that a SetHeight and SetWidth could be added; for now I just create new rects with the desired width and height...inefficient...i know...

[Nexus]

Thanks a lot for the answers! I nearly gave up hope...

I like the current design. A rectangle is built of 4 points, therefore Left/Top/Right/Bottom seems to be perfect in my opinion.

Okay, I can comprehend well this might be more intuitive for a lot cases. Probably, I only noticed the situations where a width/height would fit better. Quite possibly, the other way I'd have the same problem.

About SetWidth/SetHeight: I think it's no big deal to write a function template like the following. Or is it the calling syntax you don't like (non-member-function)?

Code: [Select]

template <typename T>
void SetWidth(sf::Rect<T>& Rect, const T& Width)
{
    Rect.Right = Rect.Left + Width;
}

Laurent, you still didn't anwer the conceptional problem of position/size-types. To be strict, GetWidth() and GetHeight() should be forbidden, shouldn't they? Or did I misunderstand you?

[Laurent]

Laurent, you still didn't anwer the conceptional problem of position/size-types. To be strict, GetWidth() and GetHeight() should be forbidden, shouldn't they? Or did I misunderstand you?

You caught me
You're right, the problem is the same in both implementations so I guess we can forget about this point.

My personal point of view about this discussion is that the best rectangle class you'll ever have is the one you write. I could make a bloated one (like the QRect class in Qt) so that everyone is happy... except me.
Users who really care about this rectangle class may just design their own one and make it convertible from/to sf::Rect, it's easy enough to do.

However I'm not against minor changes such as the SetWidth/SetHeight functions. I'll think about it

[Nexus]

Thank you for your statement, Laurent.

In fact, I am really glad your classes are not that overloaded. If you want to add functionality to a class (more exact struct), you can also think about creating global functions instead of member functions, similar to the sf::Vector2 operators.

By the way, a sf::Rect::SetWidth() function should be considered carefully. I don't know how useful it really is or if it would just bloat the class interface again. And an own solution via global function is written in a minute. Just keep this in mind...

[Laurent]

I'm glad to see that we share the same philosophy for designing classes

[Tank]

And an own solution via global function is written in a minute. Just keep this in mind...

I share that opinion *mostly*. What you also should keep in mind is that SFML is a generic multimedia library, where all those little helpers should take place, instead of enforcing 80% of the users to write their own additions. Don't get me wrong, things that users post about are mostly really too specific. But others aren't, so the sentence "It's easy to write it yourself" is sometimes absolutely misleading IMHO.

To keep on topic: I like the current sf::Rect, but wouldn't whine if it would get SetWidth() and SetHeight(). Those aren't btw. more dangerous than GetWidth() and GetHeight(), because they're counterparts.

[Nexus]

But others aren't, so the sentence "It's easy to write it yourself" is sometimes absolutely misleading IMHO.

I didn't mean it shouldn't be part of SFML because one can write it fast oneself. Rather, I actually don't see many use cases, but I can be wrong as well. For example, I use GetWidth() very often, while I initialize the sf::Rect mostly by its constructor and set the edges with absolute positions. But maybe some other SFML users should comment this, too...

The other point is that more member functions like SetWidth() tend to expand the sf::Rect class to the class with all possibilities. This can especially become confusing when there is a member function to set the internal state, but no corresponding constructor to initialize it in this way. So the width-height-concept is supported a little bit more, but not strictly enough. For those cases a wrapper class would be more convenient, in my opinion.

[Tank]

For those cases a wrapper class would be more convenient, in my opinion.

Very good idea in my opinion.