Add a \Drupal::userAccess() to replace user_access instead of \Drupal::request()->attributes->get('_account')->hasPermission()

Given that we also have many stupid patches like this in the queue:

-  global $user;
+  $user = Drupal::request()->attributes->get('_account');

.... I suggest we just do a Drupal::currentAccount() (or Drupal::account()).

@@ -391,4 +391,38 @@ public static function languageManager() {
+    return FALSE;

Null. Not false: http://www.garfieldtech.com/blog/empty-return-values

Correct. Sorry, I didn't realize the dreditor snippet would be that useless. :-)

A method should return "an object or NULL if there isn't one" or "TRUE or FALSE and nothing else". But the absence of a valid object is not untrue, it's the absence of a value. Absence of a value is NULL, not untrue.

Any time you use the value FALSE, mentally translate it to "untrue". If it doesn't make sense, then you shouldn't be using it. :-)

I do hope we're not shooting ourselves in the foot with all of these "make procedural code pretty" patches...

I'm starting to question why we have _account as a custom property on the request attributes and this being the only way to get at it. What about having a service which does this? Then we wouldn't need that actual logic in \Drupal. This is related to #2040065: Remove _account from request and use the current user service instead. just feels like we're piling hacks on at the moment.

It might well be that. In which case we either need to postpone all these issues on that one, or find an API (regardless of injected code or not) that's going to be forwards compatible with that patch so we're not doing ->get('_account') much less ->set('_account') all over the place.

I think this patch is showing that we dont need userAccess, we need a CurrentUser service:

\Drupal::currentUser()->hasPermission($permission);