8000 [Workflow] CS tweaks by ro0NL · Pull Request #19187 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[Workflow] CS tweaks #19187

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

Closed
wants to merge 5 commits into from
Closed

[Workflow] CS tweaks #19187

wants to merge 5 commits into from

Conversation

ro0NL
Copy link
Contributor
@ro0NL ro0NL commented Jun 26, 2016
Q A
Branch? master
Bug fix? no
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets ~
License MIT
Doc PR ~

Just a few minor tweaks/fixes after playing around with it. Some phpdoc should still be added imo, like missing @throws, right?

@ro0NL ro0NL changed the title minor changes [Workflow] CS tweaks Jun 26, 2016
@@ -59,10 +59,6 @@ public function getMarking($subject)
{
$marking = $this->markingStore->getMarking($subject);

if (!$marking instanceof Marking) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This should stop imo :-)

Copy link
Member
8000

Choose a reason for hiding this comment

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

Why did you removed this code ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree this should not be needed though. Otherwise it would mean that the marking store is violating the interface contract made here and here. Does that make sense ?

Copy link
Member

Choose a reason for hiding this comment

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

I'm 👎 with this change. Nothing in PHP 5 forbid someone to violate the return type of an interface.

Copy link
Contributor Author
@ro0NL ro0NL Jun 26, 2016

Choose a reason for hiding this comment

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

I guess we're not gonna agree on this. However i understand the concerns when it comes to "missing the contract and debugging", but the exception would be cosmetic only. Ie. the plain error you get 9/10 is just as informative (stacktrace wise), eventually you'll have to debug your implementation anyway. And if error handling is poor, i would advice fixing that.

is it common for users to write their own implementation of the interface

From a symfony/framework pov this is almost any interface... which is exactly why i think we have to draw the line on this.

For debugging/validating on return types; i think this should be be mostly covered by static code analysis, tests, and eventually PHP7.

This is why i changed it. :) Long story short: (imo) it's not symfony's responsibility but yes, it's DX related.

Copy link
Member

Choose a reason for hiding this comment

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

I agree with @nicolas-grekas here. We don't have that many interfaces in Symfony that should almost always be implemented by the end user.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think this interface is no different then most others. Its a pillar interface in the component with prepackaged/generic implemenations which will gonna be used 9/10.

DX-wise, the real wtf happens when PropertyAccess fails from these marking stores. You'll get an exception thats hard to relate to what you're probably doing. I also see no real added value to try/catch those and throw a WorkflowException from a previous exception, but that at least would be a true DX improvement imho.

Like i said, we're not gonna agree on this. So if symfony team votes >50% i'll remove/keep it then. Or however it's decided normally :)

Copy link
Member

Choose a reason for hiding this comment

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

@ro0NL there is no downside into keeping this, please revert this change, let's move on. We won't have a vote on this but on the PR as a whole, as always.

Copy link
Contributor Author
@ro0NL ro0NL Jun 27, 2016

Choose a reason for hiding this comment

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

OK. Im still not convinced though. Anyway hope to get some more feedback/thumbs this day then, and i'll have a look tonight. However i feel my arguments are not taken seriously.

Dont get me wrong;

on the PR as a whole

From this debate on there's no clear yes/no till now, if you ask me, besides two 👍 for the the PR. Anyway, to move on, ill revert it from a "out of scope of this PR" point of view. Under protest.

@@ -68,7 +66,7 @@ public function addPlace($place)
throw new InvalidArgumentException(sprintf('The place "%s" contains invalid characters.', $place));
}

if (!count($this->places)) {
Copy link
Contributor Author
@ro0NL ro0NL Jun 26, 2016

Choose a reason for hiding this comment

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

This is up for debate and maybe out of scope here.. but seems in line with https://github.com/symfony/symfony/pull/19187/files#diff-6d1e8dc0d2c0e7c4ab206d0efbb71516R63 😅

@fabpot
Copy link
Member
fabpot commented Jun 27, 2016

I'm again 8000 st adding @throws params except on interfaces when the contract is defined. They aren't that useful and are a nightmare to maintain especially if you start listing all possible exceptions including the ones coming from called code. And if you are not listing all of them, then it's not that useful anymore.

@ro0NL
Copy link
Contributor Author
ro0NL commented Jun 27, 2016

@fabpot do you find the custom SPL exceptions useful anyway? Symfony\..\LogicException vs. \LogicException. For type/domain checking i would be perfectly fine with the latter. Ie. imo custom exceptions only make sense when providing granularity; InvalidSomethingException for logic and SomethingNotFoundException for runtime.

Btw;

including the ones coming from called code

@throws is only used for throws directly from that method ;-)

@lyrixx
Copy link
Member
lyrixx commented Jun 27, 2016

@ro0NL custom exceptions made easier global catching. It's done like that in every other components.

@ro0NL
Copy link
Contributor Author
ro0NL commented Jun 27, 2016

@ro0NL
Copy link
Contributor Author
ro0NL commented Jun 28, 2016

Thats not the point ;-) A exception pointer interface per component is just fine, but do we need custom 1on1 SPL exceptions all the time, ie. an InvalidArgumentException per component. Or sometimes yes, sometimes no.

I see no added value in globally catching logic errors (ie programmers faults), however currently logic is thrown where its not necessarily a programmers fault. Anyway, totally out-of-scope, and guess also not something were gonna agree on :-)

Reverted the the count and instanceof changes as it seems very opinionated, which i didnt expected to be honest... from my pov the latter was the most important change code-wise.

Anyway, if this decision was rational, i guess its good to go 👍

@@ -59,6 +59,10 @@ public function getMarking($subject)
{
$marking = $this->markingStore->getMarking($subject);

if (!$marking instanceof Marking) {
throw new LogicException(sprintf('The value returned by the MarkingStore is not an instance of "%s" for workflow "%s".', Marking::class, $this->name));
Copy link
Contributor Author
@ro0NL ro0NL Jun 28, 2016

Choose a reason for hiding this comment

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

For being a contract check, i guess LogicException is just fine also :) (opposed to UnexpectedValue) 😕

@fabpot
Copy link
Member
fabpot commented Jun 28, 2016

👍

1 similar comment
@lyrixx
Copy link
Member
lyrixx commented Jun 28, 2016

👍

@ro0NL
Copy link
Contributor Author
ro0NL commented Jun 28, 2016

👍 :)

@fabpot
Copy link
Member
fabpot commented Jun 29, 2016

Thank you @ro0NL.

@fabpot fabpot closed this in f720444 Jun 29, 2016
@ro0NL ro0NL deleted the workflow/cs branch June 29, 2016 15:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants
0