-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: messageName() method is abstract by default #72
Comments
agreed! |
Yeah, agreed. |
someone wanna provide a PR? |
I'm all for it! |
All for it. Think we can remove the implementation, the presence of that method is already enforced by the |
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. |
@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;
} |
I used all tree (const, method and property) I build a map too like @enumag mentions for a custom |
@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. 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. |
Implemented on develop-branch: https://github.com/prooph/common/tree/develop |
@fritz-gerneth We have a symphony container compiler pass that automatically generates the |
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 |
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:
Thoughts?
@enumag @fritz-gerneth @basz
The text was updated successfully, but these errors were encountered: