Remove block which doesn't make sense after best practices #4929
Conversation
| Q | A |
|---|---|
| Doc fix? | yes |
| New docs? | no |
| Applies to | 2.3 |
| Fixed tickets |
| Q | A | ------------- | --- | Doc fix? | yes | New docs? | no | Applies to | 2.3 | Fixed tickets |
|
Why doesn't it make sense? It still makes very much sense, as it's showing you how to pass parameters as arguments. |
|
OK haven't thought about that, it's a valid use case. But I still think the description for example should be reworded as right now after reading it the first thing that comes to mind is it showing how to set a class for service using a parameter (which is discontinued as the best practice is just to enter the class). |
|
Hmm, indeed. The example was updated, but the description isn't. |
|
This was exactly my thought that the example was updated to follow best practices, but the description was missed. Also why I think it's not needed is because just a few paragraphs above this example there is the same code example making this a duplicate. |
|
I think you are right. It doesn't make much sense to show the example twice. |
|
Hmm, I indeed think we should remove it. We'll miss information about using parameters in service definitions, rather than just in arguments. But now class parameters are deprecated, does it make sense to tell people about it? |
|
Great detective work guys - I fully agree. Thanks! |
…s (ifdattic) This PR was merged into the 2.3 branch. Discussion ---------- Remove block which doesn't 6F1C make sense after best practices | Q | A | ------------- | --- | Doc fix? | yes | New docs? | no | Applies to | 2.3 | Fixed tickets | Commits ------- 26415e2 Remove block which doesn't make sense after best practices