Make WordPress Core

Opened 12 years ago

Closed 2 years ago

#20439 closed enhancement (maybelater)

Introduce __return_one function

Reported by: bananastalktome's profile bananastalktome Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords: close
Focuses: Cc:

Description

Following #20357 and #18845 , I feel it would be useful to have a return function for 1 for use with filters.

Attachments (1)

patch.diff (616 bytes) - added by bananastalktome 12 years ago.

Download all attachments as: .zip

Change History (12)

#1 follow-up: @scribu
12 years ago

Let's not get carried away with these.

I would argue that even __return_zero() isn't common enough.

#2 @bananastalktome
12 years ago

I've had to create my own __return_zero() in order to set defaults (which cannot be overwritten by users) with filters pre_option_default_pingback_flag, pre_option_enable_xmlrpc, pre_option_use_trackback, etc., but I could just as easily see someone wanting to force open certain options as well with a __return_one(), which is why I decided to add this patch. Many of the options listed at http://codex.wordpress.org/Option_Reference use 0 or 1 as their value, so quick returns for their filter would be at least useful to some.

#3 @nacin
12 years ago

We use 1 and 0 because it is easy to store in a DB field. In reality you can simply use __return_true and __return_false.

#4 @nacin
12 years ago

It should be noted that will work for most situations. blog_public and a few other options could hypothetically have meaningful values > 1.

#5 in reply to: ↑ 1 @nacin
12 years ago

Replying to scribu:

I would argue that even __return_zero() isn't common enough.

I just had a pretty good use case for __return_zero() — I wanted to hook into pre_option_{$option} and turn an option off. Normally I would use __return_false but that is the value passed in that needs to be changed for the bypass to work (rather than null). So 0 it is.

#6 @nacin
11 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

#7 @pcfreak30
4 years ago

  • Resolution maybelater deleted
  • Status changed from closed to reopened
  • Version set to trunk

I am aware this is old but I have lost track of the number of times I had to create a dummy function for this purpose when the calling code does a typecheck (true !== 1).

So I vote for this to be added as its simple and will get a lot of use I feel. as for __return_zero, I have used this plenty of times as well.

#8 @johnbillion
4 years ago

  • Keywords close added
  • Milestone set to Awaiting Review
  • Version trunk deleted

See the comment thread on #39240 for alternative approaches. Personally I don't think there's much demand for this as a dedicated function.

#9 @jorbin
2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from reopened to closed

Going back to maybelater as no demand has been demonstrated. Discussion can continue while the ticket is closed if there is a use case that would make a reconsideration of this decision beneficial.

#10 @pcfreak30
2 years ago

  • Resolution maybelater deleted
  • Status changed from closed to reopened

I may have moved on from this long ago, but this issue and request feel so simple, that I don't think you really can give a justification/use case for it outside the number of times you need to create this yourself in the field.

I am also surprised this is still floating around due to how simple it is.

#11 @desrosj
2 years ago

  • Resolution set to maybelater
  • Status changed from reopened to closed

Closing back out. I agree that this is a maybelater, but later is not 2022.

As noted, there are a few alternatives shared on #39240 that can be used. Just because a change is simple does not mean it's one worth making.

Note: See TracTickets for help on using tickets.