Skip to content

Add scalar typehints/return types #645

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 2 commits into from
Closed

Add scalar typehints/return types #645

wants to merge 2 commits into from

Conversation

yceruto
Copy link
Member

@yceruto yceruto commented Sep 6, 2017

@javiereguiluz
Copy link
Member

Can we have a rebase here, please? Thanks a lot!

@yceruto
Copy link
Member Author

yceruto commented Sep 7, 2017

Done.

{
return $this->id;
}

public function getTitle()
public function getTitle(): ?string
Copy link
Member

Choose a reason for hiding this comment

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

Not for this PR, but we should make the title (and slug) mandatory so this return value can never be null, don't you think?

Copy link
Member Author

@yceruto yceruto Sep 7, 2017

Choose a reason for hiding this comment

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

I thought the same at beginning, but they are already mandatory in DB & FormValidation. so when I tested the real app (/es/admin/post/new):

Type error: Return value of App\Entity\Post::getTitle() must be of the type string, null returned

The cause is on form initialization, it needs mapDataToForms() and read each defined form field from underlying object (default values), so PropertyAccessor->readProperty(array(object(Post)), 'title') calls to Post->getTitle() and boom! null value.

The solution could be set a fake or default title/slug for new Post (before form initialization), now that Slugger::slugify() is static, it can be easier. WDYT? then we would change it to strict string.

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 not sure it's worth it. Now that you explained that, I remember that I faced this issue too a while ago. I needed to put ?string in an entity because of the Form behavior that you mentioned. So let's keep it. Thanks.

@@ -36,7 +36,7 @@ public function __construct(ObjectManager $manager)
/**
* {@inheritdoc}
*/
public function transform($array)
public function transform($array): string
Copy link
Member

Choose a reason for hiding this comment

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

array typehint is missing. What if we rename the argument too from $array to $tags ?

Copy link
Member Author

Choose a reason for hiding this comment

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

array typehint is missing.

Yep, but I can't do that, because declaration must be compatible with DataTransformerInterface->transform(value).

What if we rename the argument too from $array to $tags ?

👍 Done.

@javiereguiluz
Copy link
Member

It's nice to have PHP 7.1 type hints and return types everywhere. Thanks a lot for contributing this feature!

@yceruto yceruto deleted the typehints branch September 7, 2017 17:40
@yceruto
Copy link
Member Author

yceruto commented Sep 7, 2017

Glad to help 🎉!!

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.

2 participants