The new time API

[Tex Killer]

Well, am I not dumb?  :lol:

I've read each line of the code separately.

[Groogy]

Also functioning code wasn't my point but the fact that you can read the code as normal English. Ruby is based on this concept. Example:

Code: [Select]

10.times do
  print "Hello World!"
endReading that becomes "10 times print hello world!" or even "10 times do action print hello world!" (If you take to note that the do-notation in Ruby is a lambda function)

As soon as you add more text to a name to "reduce ambiguity", reading it becomes harder. Now of course not everyone might approve of how I do it to solve ambiguity and increase readability. But since SFML is supposed to be simple I think having it close to English speech makes it that by default. As having the code written as this forces the user to maintain it simple, readable and the context in the code can be derived from the surrounding code just like in a book.

[Silvah]

From my understanding this is the proposed convention from Silvah:

Code: [Select]

time = sf::Time::FromSeconds(N);

I wasn't the one who proposed this. Mario was.

So much discussion... for a little innocent name..

No wonder, naming is the hardest thing in programming

[Nexus]

While I agree that function names should be intuitive, I wouldn't exaggerate. Long names are more difficult to read, write and remember; in my opinion they are only worth the drawbacks when they really increase the expressivity.

And I think that

Code: [Select]

sf::Time time = sf::Seconds(4);is perfectly expressive, as well as

Code: [Select]

sf::Sleep(sf::Seconds(4));
On the other side, things like

Code: [Select]

sf::Time t = sf::Time::FromSeconds(4);or

Code: [Select]

sf::Sleep(sf::Time::FromSeconds(4))are heavy and contain duplicate information, but don't give us more information about the semantics. At least no useful one -- we see that a sf::Time object is constructed, but since sf::Time is the only SFML time class, this is  obvious. Additionally, the exactly returned type isn't that important.

Also concerning sf::TimeSpan: While it is useful to differ between time points and time spans (like duration in Boost/Std), SFML doesn't have this concept, so I consider sf::Time general enough.

[Laurent]

I've pushed the new API. I didn't change anything, except the prefix: "To" is now "As".

[Groogy]

I've pushed the new API. I didn't change anything, except the prefix: "To" is now "As".

My work here is done  

[Mario]

As it's no longer possible to just use "sf::Sleep(0);" to allow context switches (or I missed something new other than calling "sf::Sleep(sf::Seconds(0));"?), how about adding something like "sf::Idle();" or "sf::Sleep(sf::Idle);" just doing that? Just a bit lazy here.

[Laurent]

There's a special Time::Zero value

Code: [Select]

sf::Sleep(sf::Time::Zero);
Is that enough?

If I implemented an "Idle" thing it would have to be specialized according to the OS, Sleep(0) is not strictly equivalent. And by the way, it would probably be named sf::Yield().

[Mario]

Sounds reasonable enough.

[Nexus]

I've pushed the new API. I didn't change anything, except the prefix: "To" is now "As".

Sounds great, I'm looking forward to update and adapt everything in Thor
(really)

[Nexus]

What do you think about an operator that returns the ratio between two times?

Code: [Select]

float operator/ (sf::Time lhs, sf::Time rhs)
{
    return lhs.AsSeconds() / rhs.AsSeconds();
}
By the way, why don't you pass sf::Time objects by value? You do it also for sf::Uint64. 8 bytes to copy is negligible, considering that references usually consume also 4 or 8 bytes. However, pass by value doesn't imply the dereferencing cost, and code becomes more beautiful without const&. In the end, you can only win

[Laurent]

What do you think about an operator that returns the ratio between two times?

What would it mean?

By the way, why don't you pass sf::Time objects by value?

I have no idea, I already do it for all other functions :lol:

[Nexus]

What would it mean?

Generally, the operator/ can be used to find out what fraction of a time span has already passed. A concrete use case looks like this:

Code: [Select]

// Returns particle lifetime progress in [0, 1]
float GetPassedRatio(const Particle& particle)
{
return GetPassedLifetime(particle) / GetTotalLifetime(particle);
}

I have no idea, I already do it for all other functions :lol:

A search&replace is performed fast

[Laurent]

Generally, the operator/ can be used to find out what fraction of a time span has already passed.

Ok. But what if one wants an integer division? Isn't it better to let users choose what type they want to manipulate for this specific use case?

A search&replace is performed fast

Yep, I'll do it.

[Nexus]

I thought this operation will be natural from a mathematical point of view, if we are able to multiply times with factors.

Code: [Select]

time1         == factor * time2
time1 / time2 == factor
However I see that there is a problem because there are operator* overloads for float and sf::Uint64...

I'm not sure whether two overloads are a good idea anyway, since it makes multiplications ambiguous for other factor types. But I also understand that providing only sf::Uint64 is too unflexible, and only float might lead to loss of precision...

In Boost.Chrono, the division of two duration<T> objects yields T as return type. Hmm, tricky :?