SFML community forums
General => General discussions => Topic started by: Laurent on June 24, 2009, 06:22:05 pm
-
Hi
It has already been discussed a long time ago, but... I still don't like the current naming convention for vectors and rectangles. I'd like to make it more consistent, while keeping it simple.
So please, tell me what you think :)
-
First, I think there is no "everyone love it" solution. But I suggest this one :
Vector2f / Rectanglef / Vector2i / Rectanglei
Because :
-> I like Vector2 so it would stand to have Rectangle instead of Rect.
-> f instead of F because it's float and not Float.
-> the same goes for i and I.
-> Not Float/Int* because the most important part of the name is Vector/Rectangle and I prefer when it's in first position.
-
It's also rather like OpenGL which is (at least in my opinion) a good Idea here so I voted with Hiura.
Btw: quite common patern emerging: 2 guys voting they have some other suggestion but no other suggestion available :D
-
I'd suggest
IntVector2 / FloatVector2 / IntRectangle / FloatRectangle
I think it fits the SFML naming convention most (like RenderTarget, WindowSettings, VideoMode etc.).
The *f and *i seem stange without a number (like 2f).
What are "Rectanglei" and "Rectanglef"?
If you read
IntRectangle Rectangle;
you already know that it is a rectangle of integers;
If you read something like
Recti Rectangle;
Rectanglei Rectangle;
it would not be that obvious. (I would have to think for a short time if those were simple typedefs or types on their own or whatever...I hope you get what I mean to say.)
Naming the vector typedefs FloatVector2 and IntVector2 would only be consistent. (Even if I like Vector2f, it just doesn't feel right in SFML).
I'd also decide against the short forms "Vec" and "Rect" and go with the full names.
But it's up to you to decide.
-
What about "CoordinateF" and "CoordinateI" or "CoordF" and "CoordI" instead of "Vector2f" and "Vector2i"?
I know, that would be a radical change but because of the name "Vector" I often swap std::vector and sf::Vector2.
-
What about "CoordinateF" and "CoordinateI" or "CoordF" and "CoordI" instead of "Vector2f" and "Vector2i"?
Because it's not only coordinates, it's also sizes and whatever which is defined by 2 or 3 components.
I know, that would be a radical change but because of the name "Vector" I often swap std::vector and sf::Vector2.
I think that std::vector is the one that would need renaming ;)
-
We're not always talking about floats. Every class having GetWidth()/GetHeight() functions should actually have one GetSize() function returning a Vector2ui.
Same for rectangles, a lot of IntRects are used in SFML.
-
Are they descended from common templates? If so the first option seems the most logical, as well as concise. At least in my opinion.
-
Yes, they are typedefs for Vector2<float>, Rect<float>, etc.
-
One another point to not chose FloatVector2 IMO is :
If we have FloatVector2 , we should have UnsignedIntVector2. Obviously it's too long.
-
I think UintVector2 would be ok, just like the Uint32/16/8 typedefs are.
-
Laurent takes the point. :P
-
I'd suggest
IntVector2 / FloatVector2 / IntRectangle / FloatRectangle
I think it fits the SFML naming convention most (like RenderTarget, WindowSettings, VideoMode etc.).
The *f and *i seem stange without a number (like 2f).
What are "Rectanglei" and "Rectanglef"?
If you read
IntRectangle Rectangle;
you already know that it is a rectangle of integers;
If you read something like
Recti Rectangle;
Rectanglei Rectangle;
it would not be that obvious. (I would have to think for a short time if those were simple typedefs or types on their own or whatever...I hope you get what I mean to say.)
Naming the vector typedefs FloatVector2 and IntVector2 would only be consistent. (Even if I like Vector2f, it just doesn't feel right in SFML).
I'd also decide against the short forms "Vec" and "Rect" and go with the full names.
But it's up to you to decide.
Totally agree.
I would stop using SFML if you changed to "Rectanglei" etc. ;) No but seriously I think it looks weird.
-
I like the current
-
If you read
IntRectangle Rectangle;
you already know that it is a rectangle of integers;
If you read something like
Recti Rectangle;
Rectanglei Rectangle;
it would not be that obvious. (I would have to think for a short time if those were simple typedefs or types on their own or whatever...I hope you get what I mean to say.)
I actually don't really understand what would be the problem whenever Recti was a typedef of a "type on its own" ? Otherwise it's only a point of view. After having used OpenGL (glVertex2i, glVertex3i, glVertex3f...) I'm quite used to the "type{dimension}{type}" naming style.
Now here is what I wrote on the French forum :
If I could change everything, this is what I would use :
Point*i/Point*f
Sizei/Sizef
Recti/Rectf
Because I think there should be a distinction between points and sizes. A size should never be negative, whereas the members of a point could (and because to me "vector" is not enough explicit). I know explanations have been given about negative size (allows inverted object drawing) but I think this is short and simple solution, but absolutely not an intuitiv one.
If I had to stay with the current vectors, here is what I'd use :
Vec2f / Rectf / Vec2i / Recti
Keeping Vector/Rect is inconsistent and to me Vector/Rectangle is too long (but I agree this last point is quite discussable and is only a question of point of view).
P.S.: I've read some complaining that if Rect was to be used instead of Rectangle, the developer would not be able to determine whether it was a type or a variable (see here (http://www.sfml-dev.org/forum-fr/viewtopic.php?p=19028#19028) (french)). This actually depends on your naming conventions : I always use capital for the first letter of a type's name and a lowercase letter for variables.
And... I've just been noticing a major point :
I think it fits the SFML naming convention most (like RenderTarget, WindowSettings, VideoMode etc.).
Recti & co does absolutely not follow this naming convention. Maybe the whole SFML naming convention should be updated (the question does not only concernes these little vectors :P ). I prefer OpenGL naming convention, thus if I was the only one to be asked, SFML would already follow this convention. But as I'm not, this should be discussed deeper, especially with the one developping SFML (hum... no.. really.. wonder what's his name :lol: ).
-
Because I think there should be a distinction between points and sizes. A size should never be negative, whereas the members of a point could (and because to me "vector" is not enough explicit). I know explanations have been given about negative size (allows inverted object drawing) but I think this is short and simple solution, but absolutely not an intuitiv one.
There no use of negative sizes to mirror objects in SFML. All integer sizes already use unsigned integers (whether they use sf::Vector2 or not), and float ones well... I can't do anything ;)
I prefer OpenGL naming convention, thus if I was the only one to be asked, SFML would already follow this convention
What "OpenGL naming conventions" are you talking about, apart from the name{dim}{type} one?
-
There no use of negative sizes to mirror objects in SFML. All integer sizes already use unsigned integers (whether they use sf::Vector2 or not), and float ones well... I can't do anything ;)
I'm not sure we're talking of the same thing, Rect is defined by Left, Top Right and Bottom, thus Left can be greater than Right, same thing for Top and Bottom. What's the behaviour in these cases ?
I prefer OpenGL naming convention, thus if I was the only one to be asked, SFML would already follow this convention
What "OpenGL naming conventions" are you talking about, apart from the name{dim}{type} one?
Lowercase for the first letter of methods (yeah I know a lot of people do not like this) and variables, short names rather than fully explicit names (ie Rect instead of Rectangle, and not only for this case!) without using hungrian naming though. I need to have a closer look at SFML interface to tell you more, but that's already part of the thing.
I agree using short naming is discussable, but until it involves confusion, it's quicker to type and use (to my mind).
-
What's the behaviour in these cases ?
For what usage of rectangles?
Lowercase for the first letter of methods
Well, it's mainly because every function has the "gl" prefix.
yeah I know a lot of people do not like this
I like it (if I could change the whole naming convention for SFML I'd do it this way) :lol:
short names rather than fully explicit
I'll never use short names. There's just no reason to use short names (with auto-completion nobody ever writes full names), and many good reasons to use long ones ;)
-
What's the behaviour in these cases ?
For what usage of rectangles?
For example with sf::Sprite::SetSubRect() ? Will the image appear inverted ?
Lowercase for the first letter of methods
Well, it's mainly because every function has the "gl" prefix.
I think it'd be the same kind of typo even without this prefix.
yeah I know a lot of people do not like this
I like it (if I could change the whole naming convention for SFML I'd do it this way) :lol:
Does it mean you can't ?
short names rather than fully explicit
I'll never use short names. There's just no reason to use short names (with auto-completion nobody ever writes full names), and many good reasons to use long ones ;)
Okkay :) .
-
Lowercase for the first letter of methods
Well, it's mainly because every function has the "gl" prefix.
I think it'd be the same kind of typo even without this prefix.
We can assume sf:: as a prefix.
-
We can assume sf:: as a prefix.
Absolutely :)
I think prefixes / namespaces are a different naming convention than function and variable names.
For example with sf::Sprite::SetSubRect() ? Will the image appear inverted ?
No, such a rectangle is not valid. But it's impossible to ensure with a structure storing left/right/top/bottom. It would be possible only with width/height, and only for integer based rectangles.
Does it mean you can't ?
I think so. But I'm tempted :D
-
Does it mean you can't ?
I think so. But I'm tempted :D
IMO you should do it. S(T)L do it that way. So why not SFML ?
-
Nothing to do with this topic but, I think sf::String should be called sf::Text.
Classes named "string" are usually meant to handle character arrays in software, and have nothing to do with rendering and viewing.
"Text" or "Label" are usually used for viewable GUI elements.
It's funny because the way of setting a string to sf::String is SetText.
I think it should be the other way around (sf::Text::SetString())
What do you think?
-Martín
-
IMO you should do it. S(T)L do it that way. So why not SFML ?
It would be more the Qt style rather than STL/boost one.
Nothing to do with this topic but, I think sf::String should be called sf::Text.
Probably ;)
Well, it seems that the discussion is sliding towards "global naming conventions in SFML" :D
Unless someone has a good argument for keeping everything like it is (that I could understand), I'm opened to any suggestion. Enjoy it, I won't do this again in the future :lol:
-
For example with sf::Sprite::SetSubRect() ? Will the image appear inverted ?
No, such a rectangle is not valid. But it's impossible to ensure with a structure storing left/right/top/bottom. It would be possible only with width/height, and only for integer based rectangles.
So why isn't a Rect composed of these two members ?
Does it mean you can't ?
I think so. But I'm tempted :D
Reminds me something :roll:
Well, it seems that the discussion is sliding towards "global naming conventions in SFML" :D
Unless someone has a good argument for keeping everything like it is (that I could understand), I'm opened to any suggestion. Enjoy it, I won't do this again in the future :lol:
Woooot ! *goes have a look at the whole SFML interface*
-
So why isn't a Rect composed of these two members ?
Because I wouldn't be able to use unsigned int size + int position, unless IntRect is a separate class from FloatRect rather than an instanciation of the same template.
Reminds me something
What?
-
I like the current Vector/Rect notation because is verbose as the rest of the library functions (But not in an extreme way).
I always liked the Open*L notation, so 2f is the clearest way to tell me that it has 2 floats. As the basic types are lower case, the letter should be to. Also, the capital D is used for other meanings, like glTexImage2D (2 dimensions, not 2 floats :)).
FloatVector2 seems to long to me. But you can always typedef to whatever makes you happy. An umbrella header is the easiest approach.
I'm more ok with the verbose versions that "Rectf/Recti" that sounds (in the later) like a latin conjugation for ASS :lol:
For these almost-basic algebraic types I like verbosity but when It doesn't exceed a length of about 10 characters. After that it starts bloating the source code and looks like crap.
Well, happy ranting to the rest xD
Regards
-Martín
-
So why isn't a Rect composed of these two members ?
Because I wouldn't be able to use unsigned int size + int position, unless IntRect is a separate class from FloatRect rather than an instanciation of the same template.
You could having a signed/unsigned typenames in the template and then using uint/int & float/float.
But anyway, it's totally impractical. The subtraction between two int/float numbers is extremely fast (them being cached in the CPU).
If it really makes a difference for a user, then he/she should keep the data duplicated within his own structure.
-
So why isn't a Rect composed of these two members ?
Because I wouldn't be able to use unsigned int size + int position, unless IntRect is a separate class from FloatRect rather than an instanciation of the same template.
It's rather annoying, because I would have like to access to the size and position members like I do for x and y. Hmm.. we have GetWidth() and GetHeight() that should be replaced with GetSize() as you mentionned on the previous page. It would be fine to also have something like GetOrigin() returning the top left point.
Reminds me something
What?
What you know about the packages :P .
I like the current Vector/Rect notation because is verbose as the rest of the library functions (But not in an extreme way).
So don't you think it should be Vector/Rectangle (or Frame ?) ? It does look more logical to me.
-
vector2f + rectf; you can write these names in a continous flow as you type in the characters on your keyboard. if you do something like vector2F, it puts a shift in the name which makes it kinda more uncomfortable to write.
-
Yes, but all the API starts with capitals. It would be incongruent to start without caps.
But float, int, double are lower case, so 2f seems better that 2F (I stress out the point about "2D" being 2-dimensions, and "2d" being 2-double-params, in OpenGL)
I like the current Vector/Rect notation because is verbose as the rest of the library functions (But not in an extreme way).
So don't you think it should be Vector/Rectangle (or Frame ?) ? It does look more logical to me.
Vector2f/Rectanglef is ok, yes. But I'm actually a conservative person...until stuff fails on me.
The "If it ain't broke, don't fix it" deal.
-
Honestly, I have never found Recti, Rectf, RectI, RectF, Rectanglei, etc..
on other lib.
And it would be awkward if SFML changing original ones to those.
:wink: