On Tue, Dec 2, 2008 at 5:55 PM, Owen Winkler <[EMAIL PROTECTED]> wrote:
>
> Chris Meller wrote:
> > 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.
>
> I'm interested in concrete examples of the classes being used in a
> correct way that can't be corrected in the class. So for example,
> empty($_POST) is invalid, whereas count($_POST) is.
I don't see what you mean here. Of course you *could* work around those
things, but why should you have to?
>
>
> Nonetheless:
>
> > 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.
>
> This seems easily fixed by adding count() and empty() methods to
> SuperGlobal, creating $_POST->count() or $_POST->empty() which are much
> more readable:
>
> if($_POST->empty()) {...}
>
> It also doesn't trigger the copy of the array, and doesn't need to
> intimate the intricacies of SPL (via getArrayCopy) to the novice coder.
Again, you're drastically changing the way someone interacts with a classic
element of the language, yet there's no concrete indication when you're
looking at the code as to why. I see $_POST all over the place and expect it
to work just as it always has. Seeing Input::post('foo') on the other hand
carries with it none of those expectations or preconceptions of behavior. As
arthus pointed out, it's also much more Habari-like.
>
>
> > 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:
>
> The reason we've avoided this approach is to implement security in a
> good way, abiding by the rule "Make it easier to do the right thing by
> default". The Input::foo() functions in other frameworks don't make it
> easier to do the right thing.
>
> Although the idea may seem more concrete, it's just a different way of
> doing input filtering that people would need to learn and (more
> importantly) also apply correctly. It's probably a greater learning
> curve than switching from count($_POST) to $_POST->count(), simply
> because until you try to do something silly like count the number of
> post submissions, you'd never encounter the problem.
>
I think that's (more than) half the point. empty( $array ) works
*everywhere* else, but not on our $_POST for some reason... That's horribly
sub-optimal in so many ways. At least clearly providing a different approach
solves this point of confusion. Even I, knowing your logic, don't see why I
would want to have to remember that it's $_POST->empty(), but empty( $tags
). To be blunt (when am I not?), that's just plain stupid...
>
> On the other hand, you'd likely be using input values all the time and
> would need to evaluate, as most devs simply don't know how to do,
> whether a value should be filtered or not. Using the SuperGlobal class
> as-is makes the default choice easy for those who don't look any deeper,
> and yet provides the required additional power to those who do.
$_POST['foo'] or Input::post('foo') vs. $_POST->raw('foo') or
Input::post('foo', false)... If you don't know whether or not it needs to be
the raw value, you don't know whether or not it needs to be the raw value -
it doesn't matter how you get at that value. We'll still have to educate
people and slap some wrists from time to time, but even if only 10% of
developers used filtered versions we'd be 10% better off than we are now.
Input::post('foo', false) also provides a consistent approach to getting the
value. $_POST['foo'] and $_POST->raw('foo') provides an array-like access
one minute and an object method access the next. Again, very inconsistent.
It may keep people from using raw values, but only by hiding them away.
That's not necessarily a bad thing, but it totally throws
even knowledgeable programmers for a loop because the interface is totally
different depending on the context.
All-in-all, there's not a technological difference or advantage to either
approach - one is just much cleaner and more straightforward than the other.
In the end, it's more Habari.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
