[PP-1] Determine how to implement Form Alters with attributes.

Remember we can use named arguments now so to me a single #[FormAlter] attribute is easier.

Alter all forms:

#[FormAlter]

Alter one form:

#[FormAlter('node_form')]

Alter all forms, specify method:

#[FormAlter(method: 'alterForm')]

I don't see the method argument being used widely anyway when we can just apply the attribute to the methods themselves?

I forgot about named arguments, that makes it much cleaner, you can even use it to help with targeting base form vs form id so we can help identify it for documentation!

I'm not even sure we need to tell the difference between base form IDs and form IDs, we don't do that at the moment with hooks except in the docblock - I'm not sure what it would gain us.

The order they are called from comes from the name. #Hook has to pass the hook name still so that is preserved. We probably want to preserve that for any child Attribute too.

It's also useful for documentation to know which hook is being called.

A bit confused about the order discussion. hook_form_BASE_FORM_ID_alter() and hook_form_FORM_ID_alter() has the same structure, there is no explicit order in hook definition. It's the same pattern, it's purely documentation thing. The order is defined by the hook invocation order: the form system will first call the hook for the base form id and then form_id, but your hook function might match both if there are conflicting form ids and base ids:

There is no "base" in this alter definition:

  /**
   * Implements hook_form_BASE_FORM_ID_alter().
   */
  #[Hook('form_node_form_alter')]
  public function formNodeFormAlter(&$form, FormStateInterface $form_state, $form_id) : void {

So, having both FormAlterById and BaseFormAlter would purely be a documentation thing about what your intention is, but the resulting hook string would be the same. looking at the example above, given that we have the intention to remove the requirement to have a Implements hook_..() docblock that might not be a bad thing to have that annotated somehow, but fairly minor difference.

I was convinced I was missing something in #5/#6, so thanks @berdir because I was thinking exactly along those lines.

your hook function might match both if there are conflicting form ids and base ids

This was a problem before, and it's still a problem now, but I don't think that is for this issue to solve.

For me I think we should just implement

#[FormAlter] === hook_form_alter
#[FormAlter('node_delete_confirm')] === hook_FORM_ID_alter or hook_BASE_FORM_ID_alter

Maybe we could have #[BaseFormAlter(...)] to identify base forms, and perhaps that will help us solve name collisions in the future, but at least to start with I think they should be treated identically - at least until we remove procedural hooks, because there is no way of identifying (except via an optional comment) which is a base form and which is not.

> This was a problem before, and it's still a problem now, but I don't think that is for this issue to solve.

Certainly, I just mentioned that to point out how similar those two hooks really are.

I think that simplifies this.

We add implements still.
Use FormAlter with an optional form id if that is provided we specify hffia.

Some future date we either add type, add a base form attribute, or deprecate base form and just leave it ambiguous.

When I started working on this I realized we can't have separate IMPLEMENTS if we have only one child attribute.

@ghost helpfully reminded me that this is also about api finding the form alters.

He suggested we add a PREFIX and SUFFIX const we can set to form and alter then pass the id in conditionally.

I'll push that up then update the IS.

This is ready for review, I think this covers all bases and will likely work for api to pick up implementations.

I think @ghost will review the api side.