[grobolom]

array_intersect_key does not do the same as array_select_keys. You can emulate it using array_intersect_key, but either in a more confusing or slow way.

  $array = ['a' => 1, 'b' => 2, 'c' => 3, 'd' => 4];

  array_select_keys($array, ['a', 'b']);
  array_intersect_key($array, ['a' => '', 'b' => '']); // OR
  array_intersect_key($array, array_flip(['a', 'b'])); // OR

Neither are elegant.

In either case, that wasn't the point. This is a basic kind of functionality that doesn't belong to any particular class in most code bases. So in this case, having a class of 'helper' functions like these isn't bad.

[rmrfrmrf]

array_intersect_key([], array_flip([])); is pretty idiomatic actually lol, but that's PHP for you.

The point still stands, though, that you shouldn't put array_select_keys into a php file filled with other helper functions. array_select_keys would go perfectly into a helper class called ArrayHelper with a bunch of other array convenience functions.

I'm pretty sure the author was talking about a helpers.php file like this:

    myGetPlaintextUserPasswordFromGET();
    encryptPasswordMD5(); //don't use this one anymore
    connect_to_my_mysql_database(); //complete with hardcoded values
    increment_for_loop();
    my_input_sanitizer();
    encryptPasswordSHA1(); //don't use thiS!!!
    my_improved_input_sanitizer(); //use this one from now on!!
    add_user_to_database();
    getCharacterAtPosition();
    generate_a_random_number_between_one_and_ten();
    show_user_alert();
    encryptPasswordSHA1_withsalt(); //USE THIS OnE!
    myConvertEmoticonToSmiley();
    ...

nightmarish.

[grobolom]

The point still stands, though, that you shouldn't put array_select_keys into a php file filled with other helper functions.

It doesn't stand. There's absolutely nothing wrong with having a file with simple helper functions.

  ArrayHelpers::array_select_keys();

is in no way better than

  array_select_keys();

There is plenty wrong with the helpers file you described at the end of your post. But it's because those functions break basic programming principles, not the fact that they happen to be simple functions in a file (and most of them are not even simple).

[rmrfrmrf]

ArrayHelpers::array_select_keys() makes it obvious that array_select_keys() is a user defined function.

ArrayHelpers helps me never wonder about where to find an array convenience function. ("array_select_keys() must be in the ArrayHelpers class" vs. "Hmm...where is that function...ugh ok let me run a find on it...oh there it is, right in between create_html_tag() and get_primes()").

ArrayHelpers lets me do lazy loading, so instead of loading everything from encrypt_password() to get_cookie_val() to do a simple task, I only get some useful array functions. Related to that, ArrayHelpers adheres to the interface segregation principle, so my function that I'm using array_select_keys() with doesn't have to know about functions that don't apply to it.

AutoHelpers helps keep my files small and maintainable. You know we've all seen helper.php files that are so monolithic that they have to be broken up with separators like this:

    ////////////////////////////////////////
    //
    //       -- ARRAY FUNCTIONS --
    //           lol oop suxx
    //
    ////////////////////////////////////////

Just to make them somewhat readable. I mean, come on, you know you've seen that.

ArrayHelpers lets me avoid obnoxious require() statements.

ArrayHelpers can be used on pretty much every future project ever without modification, so I know it will work out of the box. helpers.php on the other hand? Well, oh crap, some app-specific helpers just happened to weasel their way in there, guess I better delete them. OOPS! Deleted a semi colon by mistake and now my whole app has borked itself.

I mean, what's not to like? A few extra characters?

[grobolom]

You know we've all seen helper.php files that are so monolithic

Yes. This has nothing to do with flat functions vs. classes. I've seen 'helper' classes get shitted up just as much as function files.

My point is that it doesn't matter. Many projects don't require heavy portability, and in either case, bootstrapping a namespaced shim next to your autoloader isn't a problem.

I'm not arguing that if you have a very extensive functions library, you should separate it out. I totally agree that you should. But saying 'NEVER MAKE A FUNCTIONS FILE NEVER EVER EVER ON PAIN OF DEATH' is silly.

[PavlovsCat]

Never ever write your code to the taste of some random other person who wouldn't contribute anyway, that's my motto...