Skip to content

Conversation

@timacdonald
Copy link
Member

Making the types of these strings more explicit.

These listeners are consumed by user-land code, so having these types can improve end-user project static analysis / auto-complete.

* Get the display name for the queued job.
*
* @return string
* @return class-string
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this change is incorrect, just because the default displayName is the class, name. This could be overwritten and return any string to be displayed. (or am I wrong here?)

Copy link
Member Author

@timacdonald timacdonald Nov 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you give me a situation where this would not be a classname?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method currently returns the class string, but if you extend the class than as the method name suggests you can return any "Display name" for underlying queued job.

The Queue already has a mechanism in place which returns a different "displayName" instead of the default class.

/**
* Get the display name for the given job.
*
* @param object $job
* @return string
*/
protected function getDisplayName($job)
{
return method_exists($job, 'displayName')
? $job->displayName() : get_class($job);
}

Though this is mainly an internal class, it could also return a different "displayName" instead of the default class (I would never change the current behaviour and I am not sure, many people would do this. But I think a displayName in general is a string and not really a class-string just semantically).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the intention of this method is to always show the underlying class, as this is a wrapper class.

We can see examples of Taylor closing PRs related to custom display names: #30551

Although, I can also find an example where the opposite is true: #34620

I'm not going to open a PR to revert this, but I wouldn't be mad if you decided it was best to try a PR to revert it back to string.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Taylor already reverted it back to string in this PR. So I will leave it as is. But I also completely understand your point why it could be a class-string.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, nice. Didn't even realise haha.

Still, was good chatting :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, for me too ;)

@taylorotwell taylorotwell merged commit 0cb780c into 11.x Nov 25, 2024
32 checks passed
@taylorotwell taylorotwell deleted the class-strings branch November 25, 2024 15:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants