The new time API

[Nexus]

The new time API looks nice

Pause() in the Time class ? I wouldn't make any sense.

He probably meant Pause() in the sf::Clock class. But then Laurent would put me out of work

[Mario]

What are the function calls after the class definition for? I'm a bit confused there.

They construct time values. sf::Time has no constructor other than the default one, one must use one of these three functions.

Are they meant to be classless or is that just in that "mockup"? I'd prefer seeing them as static members in Time with "From" as prefix (similar to "To...").

[Laurent]

Are they meant to be classless or is that just in that "mockup"? I'd prefer seeing them as static members in Time with "From" as prefix (similar to "To...").

The example is pretty explicit about their usage: they are free functions, yes.
Your solution would be definitely too verbose. And having similar functions but some as static and others as non-static, could be confusing.

I don't see any pause? :- (

sf::Clock is just provided for convenience, since the most common use case for time handling is measuring the elapsed time. It's not meant to provide fancy features. I could even remove this class and replace it with a sf::Time::Now() function -- but that would be slightly less "simple"

[Mario]

Hm... I consider that pretty much standard and widely used (esp. in the .net and probably java world). It would be just a bit more sorted (having them not just sitting in the namespace).

Edit: Something like this would still look odd to me:

Code: [Select]

sf::Time &lastUse = sf::Second(someUnixTimeStampInt);
While this looks more obvious?

Code: [Select]

sf::Time &lastUse = sf::Time::FromSeconds(someUnixTimeStampInt);

[Laurent]

Hm... I consider that pretty much standard and widely used (esp. in the .net and probably java world)

These languages don't support non-member functions... So it's not "standard and widely used", it's just the only solution

It would be just a bit more sorted

It's in the same header and doc page as sf::Time. How could it be more sorted?

[mateandmetal]

new time api looks nice to me  

[Klaim]

About the pause() function : this is a real-time-passed clock system, not a virtual-time. That is good because now you can implement a virtual-time clock system specific to your game that would rely on the real-time clock.

I've done it before, it's easy to get right and you can even implement getting back in time if needed.

[model76]

Looks very nice, Laurent.

I would drop the "To" though, as it indicates a conversion, which may not always be the case. Besides, for simplicity, the user shouldn't have to care about such details.

[Groogy]

Looks very nice, Laurent.

I would drop the "To" though, as it indicates a conversion, which may not always be the case. Besides, for simplicity, the user shouldn't have to care about such details.

Agreed, "As" would be a better convention I think because it instead implies that you view something in another way instead of converting to. Though I guess that's my preference. You could do it without having a prefix as well.

Code: [Select]


Time time = /* Foobar */
time.AsSeconds();
time.AsMilliSeconds();
time.AsMicroSeconds();

It gives a cleaner readability too I think because it's more natural. You don't say "Time to seconds" you say "Time as seconds"

[Laurent]

Hmm, "As" sounds good yes.

I won't drop the prefix, because it makes it clear that the function returns the whole time value, not the seconds/milliseconds/microseconds part of it.

[Nexus]

Hm... I consider that pretty much standard and widely used (esp. in the .net and probably java world). It would be just a bit more sorted (having them not just sitting in the namespace).

I think global functions are perfectly fine for this. In C++, we fortunately don't have to put everything in classes

Edit: Something like this would still look odd to me:

Code: [Select]

sf::Time &lastUse = sf::Second(someUnixTimeStampInt);

Same to me. No wonder with a reference to a temporary

Hmm, "As" sounds good yes.

I also like it. But are there other similar functions in SFML that begin with "To"? Or maybe a future sf::Time::ToStdDuration() interacting with Chrono?

[Laurent]

But are there other similar functions in SFML that begin with "To"?

"To" functions usually apply to small utility classes that can be converted to another type, and SFML has very few of them. As far as I remember, there are "To" functions only in sf::String and sf::Utf.

Or maybe a future sf::Time::ToStdDuration() interacting with Chrono?

If I add such a conversion in the future, it will most likely be implicit. Since the type std::duration holds the semantic ("it's a duration"), unlike sf::Int32 which doesn't make it clear that you'll get milliseconds, there's no need have an explicit conversion function.

Code: [Select]

std::duration<...> d = clock.GetElapsedTime();
...looks good enough to me.

Same for the other way round:

Code: [Select]

sf::Sleep(std::seconds(1));

[Silvah]

Your solution would be definitely too verbose.

Well, I'd rather give the functions verbose names than unclear ones. "Seconds"? What does it do with seconds? Ah, let's see in the docs... it returns a Time object that represents given amount of seconds. Okay. But "Time::FromSeconds" (or "TimeFromSeconds" or anything that explicitly states what the function does) makes that clear from the beginning.

And while it may seem consistent with the standard library, it's actually not. You see, std::seconds is a type that stores some duration in seconds, so it's pretty obvious name for it. It's not a named constructor.

[Laurent]

Free functions are less clear the very first time you see them, while static member functions are confusing everytime you deal with a sf::Time instance (FromSeconds is static, ToSeconds is not -- the kind of thing that you never remember). I even expect users to post messages on the forum to ask why time.FromSeconds(n) doesn't modify their time variable.

And static functions are still very verbose. Making functions clear is the top priority, but there's a limit at which verbosity becomes important too.

And while it may seem consistent with the standard library, it's actually not. You see, std::seconds is a type that stores some duration in seconds, so it's pretty obvious name for it. It's not a named constructor.

std::seconds won't be better if the function that you're calling expects a template std::duration argument, or another specialized time class. Which might happen quite often.

[Silvah]

Free functions are less clear the very first time you see them, while static member functions are confusing everytime you deal with a sf::Time instance (FromSeconds is static, ToSeconds is not -- the kind of thing that you never remember). I even expect users to post messages on the forum to ask why time.FromSeconds(n) doesn't modify their time variable.

You missed the point. I don't care whether it's static or not. It's all about the very name:

But "Time::FromSeconds" (or "TimeFromSeconds" or anything that explicitly states what the function does) makes that clear from the beginning.

std::seconds won't be better if the function that you're calling expects a template std::duration argument, or another specialized time class

Er, what do you mean?