Skip to content
This repository was archived by the owner on Oct 20, 2025. It is now read-only.

Conversation

@BasThomas
Copy link
Contributor

No description provided.

Copy link
Contributor

@julianschiavo julianschiavo left a comment

Choose a reason for hiding this comment

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

I think it's best to leave those there so that new developers know they can use those parameters.

@BasThomas
Copy link
Contributor Author

BasThomas commented Jul 28, 2018

Wouldn't it be better to in that case show what the completionHandler does?
Something like completion: { /* do something after the view has been dismissed */ })

@julianschiavo
Copy link
Contributor

Yeah, I think that would be a good idea

Copy link
Contributor

@AvdLee AvdLee left a comment

Choose a reason for hiding this comment

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

In contrast to previous comments, I do agree we can remove the completion blocks here. They are part of the default Swift API and don't need any explanation from us.

Starting here explaining how default APIs work and with consistency in mind would require us to describe a lot more default APIs.

Therefore, we should assume implementors to be able to explore these APIs themselves.

@Boris-Em
Copy link
Contributor

Thanks for your contribution @BasThomas!

@Boris-Em Boris-Em merged commit 3a0008a into WeTransferArchive:develop Jul 30, 2018
@BasThomas BasThomas deleted the patch-1 branch July 30, 2018 11:39
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants