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

Updated file structure section to have something more generic #18

Merged
merged 6 commits into from Feb 1, 2016

Conversation

ThibaultKlein
Copy link
Collaborator

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.

@ThibaultKlein
Copy link
Collaborator Author

@paulmiard @Haud

@@ -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.
Copy link
Contributor

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).

Copy link
Collaborator Author

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?

Copy link
Collaborator

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

@Haud
Copy link
Contributor

Haud commented Feb 1, 2016

Bump @ThibaultKlein @paulmiard

@paulmiard
Copy link
Collaborator

I commented. It's on @ThibaultKlein

@Haud
Copy link
Contributor

Haud commented Feb 1, 2016

👍

@paulmiard
Copy link
Collaborator

👍

ThibaultKlein added a commit that referenced this pull request Feb 1, 2016
Updated file structure section to have something more generic
@ThibaultKlein ThibaultKlein merged commit dc2c851 into master Feb 1, 2016
@htinlinn htinlinn deleted the file_structure_update branch September 27, 2016 15:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants