On Mon, Sep 3, 2018 at 1:28 AM, Geoff Harcourt
wrote:
Would this be easier if freezing time took place in a block, and any
> unfrozen time followed the closure of the block? Then we wouldn't need a
> separate method. I think this was the recommended practice with Timecop.
>
Right. Generally
Would this be easier if freezing time took place in a block, and any
unfrozen time followed the closure of the block? Then we wouldn't need a
separate method. I think this was the recommended practice with Timecop.
On Sun, Sep 2, 2018, 6:18 PM Xavier Noria wrote:
> I think it makes sense. For
I think it makes sense. For the code to read well, both verbs have to match.
Would you like to contribute a patch?
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an
It could be set as an alias for #travel_back.
>From a semantic perspective #unfreeze_time would read like an opposite to
#freeze_time, just like #travel_back is an opposite of #travel_to
It's a relatively small change that could improve the user experience of
using #freeze_time
--
You
> On Aug 27, 2018, at 8:43 PM, Dana Sherson wrote:
>
> Currently many of the persistence methods all have different behaviours when
> it comes to whether setters are called, and validations and or callbacks are
> run,
> Knowing what happens requires deeper knowledge of rails than just
How would that method differ from the existing `travel_back`? If there is a
difference, which would be a use case?
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an
