Rename hook_permission() into hook_permission_info() for consistency

Months ago I proposed using an _info() suffix to indicate registry hooks. I believe the full proposal included a definition of:

- Had a _info() suffix.
- Returned an associative array that gets merged between all hooks.
- Had a corresponding alter hook.
- Was cached somehow so that the hook would be called only once in a blue moon. (Originally I said cached somewhere other than the cache tables as a big blob, but I think that's proven too strict a requirement.)

So we'd have:

hook_block_info()
hook_router_info() (replaces hook_menu())
hook_permission_info()
hook_theme_info()
hook_field_info() (maps to hook_content_field_info() in CCK)
hook_field_formatter_info() (maps to hook_content_field_formatter_info() in CCK)
// Various other existing CCK hooks
hook_views_tables_info() (replaces hook_views_data())

And so on. Let's go with the setup we already are beginning to establish with _info().

This is a logical change. It's also a simple one, although a lot of work.

Marking as a novice task:

1. Update all the implementations of the above hooks to match the suggested names..
2. Find all invocations of the above hooks via module_invoke() or module_invoke_all(), and change the passed hook name parameters.

@dropcube have you started work on this or may I take this one?

Eh, most of these hooks are turning into either CMI or Plugins at this point, or should be, so I don't know that it's still useful to bother with. A lot has happened in 3 years. :-)

It seems that hook_permission out of the small list of functions to rename from #3 is the only one that is still relevant (in D8).
So whats the take on this then?

hook_permission_info() would be fine by me, but I don't know if it's still doable in our current dev phase.

Well if it is then I'll get on with it.
What say you?

attached is a first patch for the permission hook
updated the following function names / calls / comments

+ hook_permission()
+ getImplementations('permission'
+ implementsHook(module, 'permission')
+ invoke(module, 'permission', ...
+ invokeAll('permission', ...

to all use permission_info

Updated function for some remaining places

+ hook_permission()
+ implementsHook(module, 'permission')

Re-titling this issue for the current purpose.

Apart from this super minor nitpick, the patch looks great. If that little thing is fixed this is RTBC.

+++ b/core/modules/filter/lib/Drupal/filter/Entity/FilterFormat.php
@@ -251,7 +251,7 @@ public function postSave(EntityStorageControllerInterface $storage_controller, $
-      // filter_permission() and lastly filter_formats(), so its cache must be
+      // filter_permission_info() and lastly filter_formats(), so its cache must be

+++ b/core/modules/filter/lib/Drupal/filter/Tests/FilterDefaultConfigTest.php
@@ -27,7 +27,7 @@ public static function getInfo() {
-    // filter_permission() calls into url() to output a link in the description.
+    // filter_permission_info() calls into url() to output a link in the description.

These should be re-formatted to fit into 80 chars.

Oops, apparently needs to be re-rolled first. Now re-titling for reals.

updated patch

Changing the status for review...

Hm. I'm not super crazy about this, personally. "info" hooks have largely gone away in favour of plugins in D8, and the ones that are left are "hook_theme()," "hook_schema()," "hook_mail()," etc. In other words, hook_permission() currently is consistent with the remaining "registry" hooks that are in D8, and I'm not sure there's a huge DX win to justify the BC break in renaming them all to something else.

Hmm.., what about $modulename.permissions.yml then?

do i need to update my patch or stop for now ?

Hmm... sadly I think unless we can think of a different approach (I'm not too fond of #22 myself, although it's certainly better than in info hook in my book) *and* rally some people to support this, there is not much point in continuing with this.

I really want to argue against #20 because it feels wrong and hook_*_info() feels right, but there is really not much to argue. Both the current consistency with hook_mail(), etc. and the fact that we probably shouldn't rename *all* of them.

:-/

Going out on a limb, unfortunately.

Hmm.., what about $modulename.permissions.yml then?

#2295469: Add support for static permission definitions with *.permissions.yml