The purpose of the Clock is to relate the passage of time in the "real" world to the passage of time in the simulated world. So the Clock is fundamentally something that exists outside of the simulation... there is no need for the simulation to know about it.
Having said that, I feel more confident that the Clock doesn't need to keep track of the total elapsed time. A lot of the time, that number won't be needed. And if it is, the simulation can easily keep track of that number itself, given the period. On Sun, Nov 20, 2016 at 1:40 AM, Gaëtan André <[email protected]> wrote: > Passing Clock.period would be indeed more useful in the example's use case. > > Could we imagine update functions where the total elapsed time is needed? > > Wouldn't it be more flexible to pass the Clock object? > > Le samedi 19 novembre 2016 18:59:02 UTC+1, Nick H a écrit : >> >> Great questions. >> >> I am wondering why you don't pass Clock.period to the update method and >>> use the global delta instead >> >> >> Reasons why period doesn't get passed directly to the update function: >> >> 1. The function would need 5 arguments, and that is too many. >> >> 2. The period is unlikely to change. The Clock needs a period, so we may >> as well set the period on the clock once, and then not worry about it. >> >> (The same could be said of the physicsUpdate function... we're unlikely >> to ever pass a different function to Clock.update. So why isn't that >> attached to the Clock record too? Because then Clock's type definition >> would need a parameter. Parametrized types are fine. But in this case, I >> thought it was better to add complexity to the function rather than the >> type.) >> >> is this counter really useful for a physical update? Wouldn't we need >>> more the real time (Clock.time*Clock.period)? >>> >> >> You're absolutely right. >> >> Actually, I think more useful than either Clock.time or >> (Clock.time*Clock.period) might be to just pass Clock.period. That way, we >> wouldn't need that global delta value any more. What do you think about >> that? >> >> Thanks for taking a look! >> ~Nick >> >> On Sat, Nov 19, 2016 at 6:01 AM, Gaëtan André <[email protected]> >> wrote: >> >>> Hi Nick, >>> >>> great effort. >>> >>> I have been looking for your code and example and I am wondering why you >>> don't pass Clock.period to the update method and use the global delta >>> instead. You also pass Clock.time a step counter, but this is not used in >>> the example, is this counter really useful for a physical update? Wouldn't >>> we need more the real time (Clock.time*Clock.period)? >>> >>> Le mercredi 16 novembre 2016 22:42:37 UTC+1, Nick H a écrit : >>>> >>>> Sorry about that. Thanks for taking proper credit! >>>> >>>> On Wed, Nov 16, 2016 at 9:23 AM, Rex van der Spuy <[email protected]> >>>> wrote: >>>> >>>>> Wow, that's absolutely brilliant!!! >>>>> (My username was `d13` by the way - so that was me!) >>>>> Congratulations!!! >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Elm Discuss" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Elm Discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
