Skip to content
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

Promote DocBlock to native types #128

Merged
merged 9 commits into from
May 27, 2021
Merged

Promote DocBlock to native types #128

merged 9 commits into from
May 27, 2021

Conversation

Slamdunk
Copy link
Contributor

No description provided.

@@ -73,7 +71,7 @@ public function canCreate(ContainerInterface $container, $requestedName)
*
* @return array
Copy link
Contributor Author

Choose a reason for hiding this comment

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

PHP Code Sniffer keeps @return array notation to let be more specific if the developer is willing to be so

@froschdesign
Copy link
Member

@Slamdunk
This is a big step. I think it would be good if we could add something to the migration guide to help the user, for example using Reactor with some rules for rewriting custom classes.

What do you think?

@Slamdunk
Copy link
Contributor Author

Even though it seems big, not even e single LOC of https://docs.laminas.dev/laminas-form/ needs to be changed (AFAICT).

The only and most common extension point is the Form, which typically only gets init() and getInputFilterSpecification() implemented, none of which requires a change.

Users so advanced to write their own Elements or ViewHelpers just need to promote the types already in use, for which I can suggest the command I've used if you wish:

$ php-cs-fixer fix --verbose --rules=phpdoc_to_param_type,phpdoc_to_return_type --allow-risky=yes

@froschdesign
Copy link
Member

@Slamdunk
I mean, a big step in a good and right direction! 😃

Users so advanced to write their own Elements or ViewHelpers just need to promote the types already in use, for which I can suggest the command I've used if you wish:

That would be great! 👍

@Slamdunk
Copy link
Contributor Author

I don't see an UPGRADE file or page, is there a standard to write and publish it in laminas org?

@driehle
Copy link
Contributor

driehle commented May 27, 2021

I created a migration/v2-to-v3.md in docs with #123, in accordance to other components, e.g. https://docs.laminas.dev/laminas-router/migration/v2-to-v3/.

@froschdesign
Copy link
Member

The documentation is the right place for this and a new page is on the way with #123

https://github.com/laminas/laminas-form/blob/17622276cefbe3f32a64d7623c3d0bc68a8e5b58/docs/book/migration/v2-to-v3.md

Slamdunk added 9 commits May 27, 2021 12:14
…urnType,MissingParamType

Signed-off-by: Filippo Tessarotto <[email protected]>
Signed-off-by: Filippo Tessarotto <[email protected]>
Signed-off-by: Filippo Tessarotto <[email protected]>
Signed-off-by: Filippo Tessarotto <[email protected]>
Signed-off-by: Filippo Tessarotto <[email protected]>
@Slamdunk Slamdunk merged commit b740ede into laminas:3.0.x May 27, 2021
@Slamdunk Slamdunk deleted the native_types branch May 27, 2021 10:56
Comment on lines +7 to +18
## Native types

laminas-form v3 promoted `@param` and `@return` annotations of non-mixed types to
the corresponding function signatures. This change should affect only highly customized
element, fieldset or form classes.
If you need to automate native types promotion, [PHP-CS-Fixer](https://github.com/FriendsOfPHP/PHP-CS-Fixer)
can help you with this command:

```console
$ php-cs-fixer fix --rules=phpdoc_to_param_type,phpdoc_to_return_type --allow-risky=yes path/to/my/custom/forms/
```

Copy link
Member

Choose a reason for hiding this comment

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

@Slamdunk
Thank you! 😃

@Slamdunk
Copy link
Contributor Author

@driehle @froschdesign I'd like to release 3.0.0 after #98 (comment)

I've already tested 3.0.x-dev in my app and found few bugs like #133, #135 and #136 linked to this PR: could you please test 3.0.x-dev too in the upcoming days?

@driehle
Copy link
Contributor

driehle commented Jun 1, 2021

I am wondering if we should probably consider #62 and #71 before the release of 3.0.0?

@froschdesign
Copy link
Member

@driehle
There is still some time before we can release version 3.0.0, because I have to extend the documentation. The versioning is missing and some other updates.

Help is welcome at any time! 😃

@Slamdunk
Copy link
Contributor Author

Slamdunk commented Jun 7, 2021

@driehle since #62 and #71 can be addressed in a minor, this morning I've released 3.0.0 to speed the things up.

Thank you very much for the big help you gave us releasing this important milestone 👍

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.

3 participants