Add action and condition shorthands to simplify the configuration

[sebastianfeldmann]

Over the last couple of versions I tried to slim the minimal required configuration down a bit.

But for internal features the action configuration still feels a bit messy.

I want to move from

{
    "action": "\\CaptainHook\\App\\Hook\\Message\\Action\\Beams"
}

To this

{
    "action": "CaptainHook.Message.MustFollowBeamsRules",
}

Similarly for the internal Conditions.

What do you think? Unnecessary or cool feature?
Feedback welcome :)

[heiglandreas]

Nice feature!

But:
Why? To use that new feature I have to know the "simplified" shorthand. Unless there is a user-readable registry that has the shorthand connected with my specific class, I will have to check Shorthand::$map constantly. And keeping that in sync with the code is an accident waiting to happen as the mapping is a manual process in a different file.

I would probably see things slightly differently when the shorthand would somehow be extracted from the fully qualified class name so that the FQCN and the shorthand van be converted into one another by a ruleset rather than a mapping.

Or when the shorthand would be defined in the respective class e.g. via a getShorthand method.

In both cases the shorthand documentation could be automatically generated without forgetting a manual process when introducing the next rule.

Also:

Why

{
    "action": "CaptainHook.Message.MustFollowBeamsRules",
}

and not

{
    "action": "CaptainHook.App.Hook.Message.Action.Beams"
}

Kind of the same as now but without the clunky backslashes...

Just my 0.02€

[sebastianfeldmann]

Very good points, especially the manual sync and how to find the shorthand.

I would update the documentation and all the examples to mainly include the shorthands, but you are right, if you don't want to look it up and see the class file it's kind of annoying to check the Shorthand::$map for clues :/

If we add the shorthand to the class, an idea that I like, how do we find the class efficiently without instantiating all the classes, on the other hand I don't want people to think they can add shorthands to their Actions and it magically works ;)

Do you think adding something like that to every Action and Condition class would "solve" or at least partially mitigate the issue?

/**
 * Example configuration:
 *
 * "action": "some-action"
 * "conditions": [
 *   {"exec": "CaptainHook.Config.CustomValueIsFalsy",
 *    "args": [
 *      "NAME_OF_CUSTOM_VALUE"
 *    ]}
 * ]

Regarding CaptainHook.App.Hook.Message.Action.Beams

Honestly my intend was to create a disconnect between namespace and shorthand, so I can move namespaces around without worrying too much. Since they are a kind of implementation detail I'm exposing right now.
And now I have to live with my bad naming ... for ever and ever :/

[sebastianfeldmann]

This is how an example configuration would look in our favorite IDE ;)