New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add #weekend?, #next_weekday, and #prev_weekday methods to Date, Time, and DateTime #18335

Merged
merged 3 commits into from Jan 6, 2015

Conversation

Projects
None yet
@georgeclaghorn
Member

georgeclaghorn commented Jan 5, 2015

Per @dhh's request in #18330:

  • #weekend? returns true if the receiving date/time falls on a Saturday or Sunday.
  • #next_weekday returns a new date/time representing the next day that does not fall on a Saturday or Sunday.
  • #prev_weekday returns a new date/time representing the previous day that does not fall on a Saturday or Sunday.

Rails already provides #yesterday and #tomorrow for dates and times, so I didn't bother implementing #prev_day or #next_day.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jan 5, 2015

Member

The reason for prev_day and next_day is that they're more natural when the date you're working on isn't today. It doesn't make sense to talk about day_in_the_far_past.tomorrow. Tomorrow/yesterday are explicitly tied to today as the reference point.

Member

dhh commented Jan 5, 2015

The reason for prev_day and next_day is that they're more natural when the date you're working on isn't today. It doesn't make sense to talk about day_in_the_far_past.tomorrow. Tomorrow/yesterday are explicitly tied to today as the reference point.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jan 5, 2015

Member

Otherwise looking good! Although I'd also like to see #next_week same_time: true.

Member

dhh commented Jan 5, 2015

Otherwise looking good! Although I'd also like to see #next_week same_time: true.

@georgeclaghorn

This comment has been minimized.

Show comment
Hide comment
@georgeclaghorn

georgeclaghorn Jan 5, 2015

Member

@dhh: I added #next_day and #prev_day — took the path of least resistance and made them aliases for #yesterday and #tomorrow.

I'll take a look at adding the :same_time option tomorrow. Assuming we want that option for the other methods that drop times, too, like #prev_week, #beginning_of_week, and #end_of_week.

Member

georgeclaghorn commented Jan 5, 2015

@dhh: I added #next_day and #prev_day — took the path of least resistance and made them aliases for #yesterday and #tomorrow.

I'll take a look at adding the :same_time option tomorrow. Assuming we want that option for the other methods that drop times, too, like #prev_week, #beginning_of_week, and #end_of_week.

@teknull

This comment has been minimized.

Show comment
Hide comment
@teknull

teknull Jan 5, 2015

I'm loving these methods. Back in 3.2.x I wrote scopes that do just this.

teknull commented Jan 5, 2015

I'm loving these methods. Back in 3.2.x I wrote scopes that do just this.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jan 5, 2015

Member

@georgeclaghorn, I'd actually prefer to have them use advance(days: 1) and advance(days: -1). yesterday/tomorrow are just not clear for this purpose. Even if the result is the same, the code is a lot less clear.

I'd like same_time on prev_week, but I don't think it makes sense on beginning_of_week and end_of_week. Those are referring to a specific moment in time.

Member

dhh commented Jan 5, 2015

@georgeclaghorn, I'd actually prefer to have them use advance(days: 1) and advance(days: -1). yesterday/tomorrow are just not clear for this purpose. Even if the result is the same, the code is a lot less clear.

I'd like same_time on prev_week, but I don't think it makes sense on beginning_of_week and end_of_week. Those are referring to a specific moment in time.

@egilburg

This comment has been minimized.

Show comment
Hide comment
@egilburg

egilburg Jan 5, 2015

Contributor

If adding weekend?, a companion weekday? could make sense

Contributor

egilburg commented Jan 5, 2015

If adding weekend?, a companion weekday? could make sense

@egilburg

This comment has been minimized.

Show comment
Hide comment
@egilburg

egilburg Jan 5, 2015

Contributor

Cultural/regional implications could also be a concern. In some countries, for example, Friday is a weekend and/or Sunday isn't. Perhaps provide API like ActiveSupport.weekend_days = [6,0] (or ActiveSupport.weekend_days = [:saturday, :sunday] and let implementation use the DAYS_INTO_WEEK enum to map.

Extracting weekend_days into Active Support class var will also prevent new array creation on each call.

Contributor

egilburg commented Jan 5, 2015

Cultural/regional implications could also be a concern. In some countries, for example, Friday is a weekend and/or Sunday isn't. Perhaps provide API like ActiveSupport.weekend_days = [6,0] (or ActiveSupport.weekend_days = [:saturday, :sunday] and let implementation use the DAYS_INTO_WEEK enum to map.

Extracting weekend_days into Active Support class var will also prevent new array creation on each call.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jan 5, 2015

Member

We define what workday and weekend means in the docs, so I'm ok with that.

Would have to be weekend_day? - not loving that.

On Jan 4, 2015, at 22:01, Eugene Gilburg notifications@github.com wrote:

Cultural/regional implications could also be a sight concern. In some countries, for example, Friday is a weekend and/or Sunday isn't.


Reply to this email directly or view it on GitHub.

Member

dhh commented Jan 5, 2015

We define what workday and weekend means in the docs, so I'm ok with that.

Would have to be weekend_day? - not loving that.

On Jan 4, 2015, at 22:01, Eugene Gilburg notifications@github.com wrote:

Cultural/regional implications could also be a sight concern. In some countries, for example, Friday is a weekend and/or Sunday isn't.


Reply to this email directly or view it on GitHub.

@senny senny added this to the 5.0.0 milestone Jan 5, 2015

@senny senny added the activesupport label Jan 5, 2015

@georgeclaghorn

This comment has been minimized.

Show comment
Hide comment
@georgeclaghorn

georgeclaghorn Jan 6, 2015

Member

@dhh:

  • Deprecated #yesterday and #tomorrow in favor of #prev_day and #next_day.
  • Added same_time option to #prev_week and #next_week.

I kept this PR divided into three separate commits and CHANGELOG entries. I'm happy to squash them if you'd prefer, but they seemed like distinct sets of changes to me.

Member

georgeclaghorn commented Jan 6, 2015

@dhh:

  • Deprecated #yesterday and #tomorrow in favor of #prev_day and #next_day.
  • Added same_time option to #prev_week and #next_week.

I kept this PR divided into three separate commits and CHANGELOG entries. I'm happy to squash them if you'd prefer, but they seemed like distinct sets of changes to me.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jan 6, 2015

Member

Sorry, I was not being clear :). I think #yesterday and #tomorrow still make sense when you're doing operations on stuff like Date#today. So don't think we need to deprecate them, but we do need prev_day and next_day doing essentially the same thing, so when you operate on not-today dates, it doesn't read odd.

Member

dhh commented Jan 6, 2015

Sorry, I was not being clear :). I think #yesterday and #tomorrow still make sense when you're doing operations on stuff like Date#today. So don't think we need to deprecate them, but we do need prev_day and next_day doing essentially the same thing, so when you operate on not-today dates, it doesn't read odd.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jan 6, 2015

Member

Also, I prefer #on_a_weekend? over #weekend? – a weekend is the whole thing, sat + sun, so to me it doesn't make sense to ask whether a single day is THE weekend. It's on a weekend, but it's not the weekend by itself.

All good with different commits 👍

Member

dhh commented Jan 6, 2015

Also, I prefer #on_a_weekend? over #weekend? – a weekend is the whole thing, sat + sun, so to me it doesn't make sense to ask whether a single day is THE weekend. It's on a weekend, but it's not the weekend by itself.

All good with different commits 👍

@georgeclaghorn

This comment has been minimized.

Show comment
Hide comment
@georgeclaghorn

georgeclaghorn Jan 6, 2015

Member

No problem. Just to make sure I'm understanding correctly, you want #prev_day and #next_weekday to have the same implementations as #yesterday and #tomorrow instead of being aliases, correct?

Member

georgeclaghorn commented Jan 6, 2015

No problem. Just to make sure I'm understanding correctly, you want #prev_day and #next_weekday to have the same implementations as #yesterday and #tomorrow instead of being aliases, correct?

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jan 6, 2015

Member

Correct :). Because the implementation is already a sort of alias by using advance, and it's just clearer that way imo.

Member

dhh commented Jan 6, 2015

Correct :). Because the implementation is already a sort of alias by using advance, and it's just clearer that way imo.

@georgeclaghorn

This comment has been minimized.

Show comment
Hide comment
@georgeclaghorn

georgeclaghorn Jan 6, 2015

Member

@dhh: OK, think everything's good now.

Member

georgeclaghorn commented Jan 6, 2015

@dhh: OK, think everything's good now.

georgeclaghorn added some commits Jan 5, 2015

Add #on_weekend?, #next_weekday, and #prev_weekday methods to Date, T…
…ime, and DateTime

`#on_weekend?` returns true if the receiving date/time falls on a Saturday or
Sunday.

`#next_weekday` returns a new date/time representing the next day that does
not fall on a Saturday or Sunday.

`#prev_weekday` returns a new date/time representing the previous day that
does not fall on a Saturday or Sunday.
@kuldeepaggarwal

This comment has been minimized.

Show comment
Hide comment
@kuldeepaggarwal

kuldeepaggarwal Jan 6, 2015

Contributor

@dhh: yes, I agree that the weekend is the whole thing sat + sun, but here we just want to know whether today is sat or sun not both, as today can be either of them. So IMO weekend? should be more appropriate in this scenario.

Contributor

kuldeepaggarwal commented Jan 6, 2015

@dhh: yes, I agree that the weekend is the whole thing sat + sun, but here we just want to know whether today is sat or sun not both, as today can be either of them. So IMO weekend? should be more appropriate in this scenario.

dhh added a commit that referenced this pull request Jan 6, 2015

Merge pull request #18335 from georgeclaghorn/day-gymnastics
Add #weekend?, #next_weekday, and #prev_weekday methods to Date, Time, and DateTime

@dhh dhh merged commit 0d28543 into rails:master Jan 6, 2015

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details
@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jan 6, 2015

Member

Thanks @georgeclaghorn!

@kuldeepaggarwal I don't quite follow that argument. on_weekend is similar to the form of "[object] in? [set]".

Member

dhh commented Jan 6, 2015

Thanks @georgeclaghorn!

@kuldeepaggarwal I don't quite follow that argument. on_weekend is similar to the form of "[object] in? [set]".

end
# Returns a new date/time representing the next day.
def next_day

This comment has been minimized.

@kuldeepaggarwal

kuldeepaggarwal Jan 6, 2015

Contributor

@dhh: I think this might be an alias of tomorrow. wdyt?

@kuldeepaggarwal

kuldeepaggarwal Jan 6, 2015

Contributor

@dhh: I think this might be an alias of tomorrow. wdyt?

This comment has been minimized.

@dhh

dhh Jan 6, 2015

Member

It could have been, and @georgeclaghorn initially implemented it as such, but I find that more confusing. Clarity > DRY.

@dhh

dhh Jan 6, 2015

Member

It could have been, and @georgeclaghorn initially implemented it as such, but I find that more confusing. Clarity > DRY.

This comment has been minimized.

@kuldeepaggarwal

kuldeepaggarwal Jan 6, 2015

Contributor

Great... 👍

@kuldeepaggarwal

kuldeepaggarwal Jan 6, 2015

Contributor

Great... 👍

@georgeclaghorn georgeclaghorn deleted the georgeclaghorn:day-gymnastics branch Jan 6, 2015

@donaic

This comment has been minimized.

Show comment
Hide comment
@donaic

donaic Jan 10, 2015

What about is_business_day? and next_business_day

donaic commented Jan 10, 2015

What about is_business_day? and next_business_day

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jan 10, 2015

Member

How would those differ from weekday?

On Jan 9, 2015, at 9:09 PM, donaic notifications@github.com wrote:

What about is_business_day? and next_business_day


Reply to this email directly or view it on GitHub #18335 (comment).

Member

dhh commented Jan 10, 2015

How would those differ from weekday?

On Jan 9, 2015, at 9:09 PM, donaic notifications@github.com wrote:

What about is_business_day? and next_business_day


Reply to this email directly or view it on GitHub #18335 (comment).

@georgeclaghorn

This comment has been minimized.

Show comment
Hide comment
@georgeclaghorn

georgeclaghorn Jan 10, 2015

Member

I'm not opposed to weekday? as a complement to on_weekend?, but I don't think next_business_day is a necessary alias for next_weekday.

Member

georgeclaghorn commented Jan 10, 2015

I'm not opposed to weekday? as a complement to on_weekend?, but I don't think next_business_day is a necessary alias for next_weekday.

@donaic

This comment has been minimized.

Show comment
Hide comment
@donaic

donaic Jan 10, 2015

Holidays are not business day. This may be too country specific to be useful, but thought it would be worth a discussion. Could have default holidays that can be modified as necessary.

donaic commented Jan 10, 2015

Holidays are not business day. This may be too country specific to be useful, but thought it would be worth a discussion. Could have default holidays that can be modified as necessary.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jan 10, 2015

Member

Don’t think we need any aliases here.

On Jan 9, 2015, at 9:15 PM, George Claghorn notifications@github.com wrote:

I'm not opposed to weekday? as a complement to on_weekend?, but I don't think next_business_day is a necessary alias for next_weekday.


Reply to this email directly or view it on GitHub #18335 (comment).

Member

dhh commented Jan 10, 2015

Don’t think we need any aliases here.

On Jan 9, 2015, at 9:15 PM, George Claghorn notifications@github.com wrote:

I'm not opposed to weekday? as a complement to on_weekend?, but I don't think next_business_day is a necessary alias for next_weekday.


Reply to this email directly or view it on GitHub #18335 (comment).

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jan 10, 2015

Member

Ah, I see. Yeah, I think that’s very country/company specific. I don’t think that’d be a good fit for core, but could make an interesting plugin.

On Jan 9, 2015, at 9:16 PM, donaic notifications@github.com wrote:

Holidays are not business day. This may be too country specific to be useful, but thought it would be worth a discussion. Could have default holidays that can be modified as necessary.


Reply to this email directly or view it on GitHub #18335 (comment).

Member

dhh commented Jan 10, 2015

Ah, I see. Yeah, I think that’s very country/company specific. I don’t think that’d be a good fit for core, but could make an interesting plugin.

On Jan 9, 2015, at 9:16 PM, donaic notifications@github.com wrote:

Holidays are not business day. This may be too country specific to be useful, but thought it would be worth a discussion. Could have default holidays that can be modified as necessary.


Reply to this email directly or view it on GitHub #18335 (comment).

@teknull

This comment has been minimized.

Show comment
Hide comment
@teknull

teknull Jan 10, 2015

I really love where this is going, I've written tons of scopes and methods that do similar back in 3.2.x. Would love to help.

On Jan 9, 2015, at 20:17, David Heinemeier Hansson notifications@github.com wrote:

Ah, I see. Yeah, I think that’s very country/company specific. I don’t think that’d be a good fit for core, but could make an interesting plugin.

On Jan 9, 2015, at 9:16 PM, donaic notifications@github.com wrote:

Holidays are not business day. This may be too country specific to be useful, but thought it would be worth a discussion. Could have default holidays that can be modified as necessary.


Reply to this email directly or view it on GitHub #18335 (comment).


Reply to this email directly or view it on GitHub.

teknull commented Jan 10, 2015

I really love where this is going, I've written tons of scopes and methods that do similar back in 3.2.x. Would love to help.

On Jan 9, 2015, at 20:17, David Heinemeier Hansson notifications@github.com wrote:

Ah, I see. Yeah, I think that’s very country/company specific. I don’t think that’d be a good fit for core, but could make an interesting plugin.

On Jan 9, 2015, at 9:16 PM, donaic notifications@github.com wrote:

Holidays are not business day. This may be too country specific to be useful, but thought it would be worth a discussion. Could have default holidays that can be modified as necessary.


Reply to this email directly or view it on GitHub #18335 (comment).


Reply to this email directly or view it on GitHub.

@shireeshj

This comment has been minimized.

Show comment
Hide comment
@shireeshj

shireeshj Jan 10, 2015

Many countries follow different work week. Assuming Saturday+Sunday could be limiting the scope.
For example Isreal, UAE etc. see wikipedia

shireeshj commented Jan 10, 2015

Many countries follow different work week. Assuming Saturday+Sunday could be limiting the scope.
For example Isreal, UAE etc. see wikipedia

@donaic

This comment has been minimized.

Show comment
Hide comment
@donaic

donaic Jan 10, 2015

What about is_monday? etc...

donaic commented Jan 10, 2015

What about is_monday? etc...

@georgeclaghorn

This comment has been minimized.

Show comment
Hide comment
@georgeclaghorn

georgeclaghorn Jan 10, 2015

Member

@donaic: Ruby core has that covered with #monday?, #tuesday?, etc.

Member

georgeclaghorn commented Jan 10, 2015

@donaic: Ruby core has that covered with #monday?, #tuesday?, etc.

@ecleel

This comment has been minimized.

Show comment
Hide comment
@ecleel

ecleel Jan 11, 2015

I agree with @egilburg we need a way to change a #weekend? days from the default [Sat and Sun] to country specific, e.g. in Saudi Arabia weekend now is Friday and Saturday.

Perhaps if we can use locale files to do that.

ecleel commented Jan 11, 2015

I agree with @egilburg we need a way to change a #weekend? days from the default [Sat and Sun] to country specific, e.g. in Saudi Arabia weekend now is Friday and Saturday.

Perhaps if we can use locale files to do that.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jan 11, 2015

Member

It's more work to add and set a config than just overwriting this method in your local app.

On Jan 11, 2015, at 02:13, Abdulaziz AlShetwi notifications@github.com wrote:

I agree with @egilburg we need a way to change a #weekend? days from the default [Sat and Sun] to country specific, e.g. in Saudi Arabia weekend now is Friday and Saturday.

Perhaps if we can use locale files to do that.


Reply to this email directly or view it on GitHub.

Member

dhh commented Jan 11, 2015

It's more work to add and set a config than just overwriting this method in your local app.

On Jan 11, 2015, at 02:13, Abdulaziz AlShetwi notifications@github.com wrote:

I agree with @egilburg we need a way to change a #weekend? days from the default [Sat and Sun] to country specific, e.g. in Saudi Arabia weekend now is Friday and Saturday.

Perhaps if we can use locale files to do that.


Reply to this email directly or view it on GitHub.

@guilleiguaran

This comment has been minimized.

Show comment
Hide comment
@guilleiguaran

guilleiguaran Jan 11, 2015

Member

+1 for overwriting in this case

On Sun, Jan 11, 2015 at 10:32 AM, David Heinemeier Hansson <
notifications@github.com> wrote:

It's more work to add and set a config than just overwriting this method
in your local app.

On Jan 11, 2015, at 02:13, Abdulaziz AlShetwi notifications@github.com
wrote:

I agree with @egilburg we need a way to change a #weekend? days from the
default [Sat and Sun] to country specific, e.g. in Saudi Arabia weekend now
is Friday and Saturday.

Perhaps if we can use locale files to do that.


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub
#18335 (comment).

Member

guilleiguaran commented Jan 11, 2015

+1 for overwriting in this case

On Sun, Jan 11, 2015 at 10:32 AM, David Heinemeier Hansson <
notifications@github.com> wrote:

It's more work to add and set a config than just overwriting this method
in your local app.

On Jan 11, 2015, at 02:13, Abdulaziz AlShetwi notifications@github.com
wrote:

I agree with @egilburg we need a way to change a #weekend? days from the
default [Sat and Sun] to country specific, e.g. in Saudi Arabia weekend now
is Friday and Saturday.

Perhaps if we can use locale files to do that.


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub
#18335 (comment).

@egilburg

This comment has been minimized.

Show comment
Hide comment
@egilburg

egilburg Jan 11, 2015

Contributor

API implies Rails supports this as a feature, and will ensure that whatever code is built upon this later will remain working when the API is used. Developers overwriting core extensions means they entering "hacker territory" and are on their own in dealing with whatever consequences bubble up as a result.

That being said, I concede it's not currently a pragmatic difference in this particular part of the code.

Contributor

egilburg commented Jan 11, 2015

API implies Rails supports this as a feature, and will ensure that whatever code is built upon this later will remain working when the API is used. Developers overwriting core extensions means they entering "hacker territory" and are on their own in dealing with whatever consequences bubble up as a result.

That being said, I concede it's not currently a pragmatic difference in this particular part of the code.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jan 11, 2015

Member

A config option would have the same effect as overwriting the method will.

On Jan 11, 2015, at 10:22 AM, Eugene Gilburg notifications@github.com wrote:

API implies Rails supports this as a feature, and will ensure that whatever code is built upon this later will remain working when the API is used. Developers overwriting core extensions means they entering "hacker territory" and are on their own in dealing with whatever consequences bubble up as a result.

That being said, I concede it's not currently a pragmatic difference in this particular part of the code.


Reply to this email directly or view it on GitHub #18335 (comment).

Member

dhh commented Jan 11, 2015

A config option would have the same effect as overwriting the method will.

On Jan 11, 2015, at 10:22 AM, Eugene Gilburg notifications@github.com wrote:

API implies Rails supports this as a feature, and will ensure that whatever code is built upon this later will remain working when the API is used. Developers overwriting core extensions means they entering "hacker territory" and are on their own in dealing with whatever consequences bubble up as a result.

That being said, I concede it's not currently a pragmatic difference in this particular part of the code.


Reply to this email directly or view it on GitHub #18335 (comment).

@shireeshj

This comment has been minimized.

Show comment
Hide comment
@shireeshj

shireeshj Jan 14, 2015

I agree with @egilburg. It is kind of natural to expect a core extension to be "complete", especially something that has got to do with date and time (because the rules for these are well defined and understood, as opposed to say, strings).

shireeshj commented Jan 14, 2015

I agree with @egilburg. It is kind of natural to expect a core extension to be "complete", especially something that has got to do with date and time (because the rules for these are well defined and understood, as opposed to say, strings).

@johnnyshields

This comment has been minimized.

Show comment
Hide comment
@johnnyshields

johnnyshields Jan 17, 2015

Contributor

FYI we have a lot of this stuff in the ByStar gem (https://github.com/radar/by_star).

Contributor

johnnyshields commented Jan 17, 2015

FYI we have a lot of this stuff in the ByStar gem (https://github.com/radar/by_star).

@rafaelfranca rafaelfranca modified the milestones: 5.0.0 [temp], 5.0.0 Dec 30, 2015

@vipulnsward

This comment has been minimized.

Show comment
Hide comment
@vipulnsward

vipulnsward Feb 14, 2016

Member

@dhh wdyt about having on_weekday?, compliment on_weekend? here?

PS: Would also love to hear your thoughts on prev to previous. Having short prefix prev scattered everywhere can be a bit confusing.

Member

vipulnsward commented Feb 14, 2016

@dhh wdyt about having on_weekday?, compliment on_weekend? here?

PS: Would also love to hear your thoughts on prev to previous. Having short prefix prev scattered everywhere can be a bit confusing.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Feb 15, 2016

Member

Fine with adding on_weekday? to complete the set. Not sure I understand the question re: prev? It doesn't stand alone, it goes with prev_workday.

Member

dhh commented Feb 15, 2016

Fine with adding on_weekday? to complete the set. Not sure I understand the question re: prev? It doesn't stand alone, it goes with prev_workday.

@vipulnsward

This comment has been minimized.

Show comment
Hide comment
@vipulnsward

vipulnsward Feb 15, 2016

Member

So the question was about using previous, instead of prev, like previous_weekday, etc. We usually don't use short names on methods.
I see that we have been using methods like prev_month, prev_year before, so this is ok I guess.

Member

vipulnsward commented Feb 15, 2016

So the question was about using previous, instead of prev, like previous_weekday, etc. We usually don't use short names on methods.
I see that we have been using methods like prev_month, prev_year before, so this is ok I guess.

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Feb 15, 2016

Member

Ah, yes. Following prior pattern as well as the concern that this is a method you'd frequently want to type on say a console.

Member

dhh commented Feb 15, 2016

Ah, yes. Following prior pattern as well as the concern that this is a method you'd frequently want to type on say a console.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment