The SuperGlobals implementation is novel and sounds great in theory, but
hasn't stood up in practice. Having an object instead of a true array has
made numerous things more difficult, especially if you're writing code that
expects normal $_* arrays. In the end, it tries so hard to behave like the
native $_* arrays, but falls just short enough that it'll easily drive you
into madness.
A few examples I ran into while trying to fix the WordPress importer:
empty( $_POST ) always returns false. count( $_POST ) returns 0.
isset( $_POST ) would obviously never work, since $_POST is always set. I'd
never have done that, but whoever wrote the WP importer did (we really need
to finish those coding standard)... I don't know that we could fix that
without risking errors because people call methods on non-objects if it no
longer exists. Using empty() would probably be better, but...
In order to use any of our pseudo-arrays as actual arrays, you have to
remember to use ->getArrayCopy() or ->get_array_copy_raw(). That's
annoying... and it hurts my fingers. It also doesn't let you use it in
conditions such as if ( empty( $_POST->getArrayCopy() ) ) because you can't
use a method return value in a write context. Setting a temporary variable
to the result array and testing against that is a waste of code and time.
And just when you think I'm going to complain and run, here's another
suggested approach, based a lot on the CodeIgniter and (more so) Kohana
frameworks' implementations:
Input::get($index, $filtered = true) { ... }
Input::post($index, filtered = true) { ... }
Input::server($index, $filtered = true) { ... }Input::cookie($index,
$filtered = true) { ... }
$foo = Input::get('foo'); // $_GET['foo'], filtered
$foo = Input::get('foo', false); // $_GET['foo'], unfiltered
While I would personally never simply check for isset or empty $_* for those
who would and in instances where a true array of everything is needed, we
provide a simple array of each: Input::$get, Input::$post, Input::$server,
and Input::$cookie. That means if ( empty( Input::$get ) ) works fine once
again. The naming scheme for an un-filtered version is up for debate...
The basic principle here is that we don't use $_* - they're obsolete and can
be filtered or totally unset all together. The key is that we don't even try
to use them, thereby avoiding confusion when people think they know what
kind of behavior to expect.
As a simpler, more retro solution, we could always just filter $_* directly
and provide some other similarly-named array that contains raw values. I'm
not big on that approach, but it's always still an option.
I do still like the idea of being forced to get a single input value at a
time, as in my opinion it forces you to hold the reigns on your data and
what data you're accepting more tightly, but no matter how it's implemented
that is going to require a good deal of code refactoring in a variety of
hidden-away places that will probably never throw errors. If we decide to go
with that kind of approach (either the current one, or a new one), I think
everyone needs to be more mindful of the pitfalls and be on the lookout for
things like that - it seems like I'm the only one at present who's noticed.
Fixing things like that can be difficult when it's not code you wrote and
you don't know exactly which fields can, should, and might be submitted by
any given form...
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/habari-dev
-~----------~----~----~----~------~----~------~--~---
