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
Updated file structure section to have something more generic #18
Conversation
@@ -14,12 +14,23 @@ If there is anything you are looking for that is not covered here you should ref | |||
|
|||
### File structure ### | |||
|
|||
You should not define multiple public/internal types (ie class, struct, enum) in the same file; each type should have its own file. | |||
You should not define multiple public/internal types (ie class, struct, enum) in the same file; each type should have its own file. If an enum or protocol is related to the class but has to be known outside define it inside the class file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we discussed this and the idea is, given that enums are their own types, they should be in their file, regardless of whether they are a "part" of a class or not. I feel like this definition is too vague -- because even if the enum is only declared as a property in one area, that doesn't mean that other classes use it. It also then opens up issues of how to deal with refactoring enums into their own file when their use case changes -- I feel like this is will not happen and makes things more complicated than they need to be.
Since types are first-class citizens in Swift, I believe they should always be in their own code file unless they are private (for obvious reasons).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand your point but that's against what we were used to do in Objective-C by having enum in the header file related to the class where it's used. Are we considering enums as separate types not related to a class or more a helper type that should live with the feature it's related to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per our discussion today let's get rid of "If an enum or protocol is related to the class but has to be known outside define it inside the class file." and keep things simple
Bump @ThibaultKlein @paulmiard |
I commented. It's on @ThibaultKlein |
👍 |
b3ee086
to
b7daf67
Compare
👍 |
Updated file structure section to have something more generic
Updated the file structure to add more details on enums and protocols to include the case where an enum / protocol is related to a class but has to be internal.
Updated the MARK section to remove the extra details and examples and leave more options to the developers on how to use them.