[wp-trac] [WordPress Trac] #22325: Abstract GPCS away from the superglobals

[WordPress Trac]

#22325: Abstract GPCS away from the superglobals
-------------------------+-----------------------------
 Reporter:  rmccue       |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  General      |     Version:
 Severity:  minor        |  Resolution:
 Keywords:               |
-------------------------+-----------------------------

Comment (by MikeSchinkel):

 Replying to [comment:18 CaptainN]:
 > I'm approaching this from an API design perspective. My primary goal is
 to make the API not suck. :-)

 That's exactly my reason too.  But as is typical with two programmers, we
 have three opinions and they are all different. :)

 > Replying to [comment:17 MikeSchinkel]:
 > The only weird thing with that, is I tend to think of array values as
 "next to" rather than "in to". That they are used essentially as pivot
 tables is a bit weird to me (but it's not unprecedented, and it's not
 bad). I suppose using multiple function arguments could be said to employ
 a similar hack, and multiple args does limit the ability to conveniently
 set a default in there.

 Another benefit is the `$key` is a single value which can be stored and
 passed around as a single item.  You could still do that with your
 approach but accessing it would require the decidedly obtuse approach of:

 {{{
 $value = call_user_func_array( '_get', $keys_as_array );
 }}}

 I personally would prefer to just know the `_GET()`'s first parameter is
 always the key in whatever form the key takes.

 > If you set a default value in a form (like "enter first name", or some
 invalid value in a select box, or even just an empty string), and you want
 the user to change the default, you'd have to check it on post back.
 has_GET only checks if the key is in the array.

 Seems like this would work fine:

 {{{
 $first_name = _GET( 'first_name' );
 if ( is_null( $first_name ) ||  "enter first name" == $first_name )
    echo "Sorry, you must enter a first name please.";
 }}}

 That use-case is also mutually exclusive from the need for a default value
 so I don't see the default value conflicting with a placeholder.  If it
 did however, here is a contrived example:

 {{{
 $first_name = _GET( 'first_name' );
 if ( "enter first name" == $first_name )
    echo "Sorry, you must enter a first name please.";
 else
    $first_name = 'John Doe';
 }}}

 This could somehow be turned into an expression by adding your
 `_default()` function but that's adding another helper method and I would
 prefer to keep the number of new WordPress' specific functions we have to
 learn to a minimum. If we want to add a `_default()` and `_check()` I'd
 propose creating a new ticket proposing that WordPress add them.

 But if you ''really'' want a single expression:

 {{{
 $first_name = _GET( 'first_name', 'John Doe', 'enter first name' )
 if ( is_wp_error( $first_name ) )
    echo "Sorry, you must enter a first name please.";
 }}}

 Or even:

 {{{
 $first_name = _GET( 'first_name', 'John Doe', array(
    'stop_value' => 'enter first name',
    'not_empty' => true,
 ));
 if ( is_wp_error( $first_name ) )
    switch ( $first_name->get_error_code() ) {
       case 'empty':
       case 'invalid_value':
          echo "Sorry, you must enter a first name please.";
          break
    }
 }}}

 But I wouldn't advocate for that level of complexity.

 > Or if you need to check for a default value:
 >
 > {{{
 > // old way:
 > if ( isset( $_GET['myVar'] ) && 'default value' != $_GET['myVar'] )
 >
 > // vs:
 > if ( _check( _get( 'myVar' ), 'default value' ) )

 This adds even more surface area to WordPress.  There's a cost in terms of
 runtime overhead, and learning; everyone will need to learn what
 `_check()` does. People who are familiar with PHP don't have to learn
 this:

 {{{
 if ( isset( $_GET['myVar'] ) && 'default value' != $_GET['myVar'] )
 }}}
 > ...
 > The ... are way better than the "old way".

 Syntactical sugar in PHP is good IMO but adding helper functions in
 libraries and frameworks usually just adds unnecessary complexity. In my
 past where I went crazy with helper functions but learned that too much is
 not a good thing; best to just stick with what exists.

 In the case of the proposed `_GET()`, we'd already be are adding it so we
 can kill three (3) birds with one stone; #2: Be graceful when $_GET['foo']
 doesn't exist, and #3: Allow us to add a default value when we need one.

 > // vs:
 > if ( _GET( 'myVar', 'default value' ) != 'default value' )
 > // or:
 > if ( has_GET( 'myVar' ) && _GET( 'myVar' ) != 'default value' )
 > }}}

 You got that last one wrong.  It should just be:

 {{{
 > if ( _GET( 'myVar' ) != 'default value' )
 }}}

 > And finally to output the value:
 >
 > // vs:
 > echo _default( _get( 'myVar'), 'default value' );
 >
 > // vs:
 > echo _GET( 'myVar', 'default value' );
 > }}}

 It's clear which of these I prefer. :)

 Replying to [comment:19 CaptainN]:
 > Also note, your implementation would need to do something similar.

 Agreed. I didn't address that part because I don't understand the
 requirements 100%.  I was focused on suggesting an API that I think
 doesn't suck, much as you were. :)

 But given that it's WordPress I would guess they might simply want to use
 the object cache?

 So...we've now both made our cases. But neither of us makes the decision.
 :)  I'm just going to  leave it to let others give their opinions, and
 eventually @nacin or someone else from the core team will decide.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/22325#comment:20>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software