Advanced argument handling design choices

There are two design choices with regard to advanced argument handling in GOOPS methods which are worth explaining.

First, there was the choice whether to add this functionality to method and define-method proper or to introduce new syntax method* and define-method*.

There are several reasons why it could be better not to introduce new syntax. It would give a simpler API, with less cognitive load for the user, and a slightly simpler implementation (compared to providing the new syntax as well). It would align with the CLOS design choice where defmethod does support advanced argument handling.

Eventually, we decided to introduce new syntax instead of extending the old for the following reasons:

1. It aligns with lambda* and define*.
2. It is somewhat better at protecting backward compatibility.
3. It preserves the conceptual simplicity of method and define-method.
4. It makes it easier for other implementations (like guile-hoot) to choose to only provide the simpler functionality (through method and define-method).

However, note that users who prefer to only use define-method can do so. See Advanced argument handling in method and define-method.

Second, we have chosen not to do type dispatch on optional or keyword arguments. Reasons include:

1. It strikes a reasonable balance with regards to the complexity of implementation (and cognitive load for the user).
2. It aligns with the CLOS implementation which also likely had good reasons for this choice.
3. Currently, we don’t have clear ideas about a conceptual framework of rules governing type dispatch for advanced argument handling or how this would be implemented.