RFC: messageName() method is abstract by default

[prolic]

I would like to propose that the messageName() method is abstract by default (which means you have to implement it on every class). The MessageFactory hence needs a message map, in order to create an object from message data, because the messageName doesn't have to be the class name. Class name as messsage name by default is removed.

Reasons:

• for prooph/event-store-client we need messageMap anyway
• it allows custom message names by default, lots of users asked on how not to have class name as message name and needed to write custom message factories in order to do this. Even with blog posts about this out there, the question came again and again. Actually nobody I'm aware of wants to have the class name as message name, hence why not change it now?

Thoughts?

@enumag @fritz-gerneth @basz

[basz]

agreed!

[enumag]

Yeah, agreed.

[prolic]

someone wanna provide a PR?

[mbadolato]

I'm all for it!

[fritz-gerneth]

All for it. Think we can remove the implementation, the presence of that method is already enforced by the Message interface anyway

[enumag]

The problem is that in my opinion the method should be static which it is not. When you find all messages via some composer autoloader magic or something like symfony/finder and want to build the map you need to call the method. Sure you can call non-static method by creating an instance without constructor using reflection but it's not ideal. What do you guys think?

EDIT: If we do change messageName to static we should do the same with messageType as well.

[fritz-gerneth]

@enumag We're usually exposing the message name as a constant anyway. The method only returns the constant's value:

final class OurAwesomeCommand extends Command implements PayloadConstructable
{
    use PayloadTrait;

    public const COMMAND_NAME = 'message-name-string';

    protected $messageName = self::COMMAND_NAME;
}

[callistino]

I used all tree (const, method and property) I build a map too like @enumag mentions for a custom NameMessageFactory and so far the constant helps but it's a construct that we shouldn't need to use if the method was static.

[fritz-gerneth]

@callistino we sure are uing it for the same reason. But this map does not exist for the reason ob getting the message name when you have the message. For this the existing method is used exactly.
It is used for the reverse way of getting the class name for a respective message name. For this no static method can help you anyway.

Besides this, I personally think having static methods on interfaces is a bad design. The message name is a property of a given message object. A static one, but yet a property of the object. Having some gettings of a class static just because they can makes a class much less of a class.

[prolic]

Implemented on develop-branch: https://github.com/prooph/common/tree/develop

[callistino]

@fritz-gerneth We have a symphony container compiler pass that automatically generates the NameMessageFactory class and it uses reflection to get the name for any class implementing HasMessageName interface to build the map. With a static method we wouldn't need an instance, or a container reflector class. That's why we use the constant but a static method would make it unnecessary.

[prolic]

This library will receive support until December 31, 2019 and will then be deprecated.

For further information see the official announcement here: https://www.sasaprolic.com/2018/08/the-future-of-prooph-components.html