[Setup] Structure of Files and Nested Types #105
-
DescriptionFor feedback on my Assignment #1, I was told to void nested types for now. ReproductionFor example, for the Patient class, I nested the age variable within this class. Is it recommended that I create an entire separate file for this variable or can I declare this variable within the same file as the Patient class, but not nested within this class? Thank you! Expected behaviorI am assuming the behavior would be the same, but it is more of a question of style. Additional contextNo response Code of Conduct
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Hi @kkarenvoo05, Thank you for asking a question here on GitHub! I think there might be a confusion between nested types (see Apple Swift Documentation) and type properties (great article provide an overview of what's possible in Swift). Nested types are a great way to structure types that are very closely bound to each other and where a type-based name scoping makes sense (such as the cards example in the documentation). The feedback for assignment 1 was probably targeted to a nested type that would make sense to be used across the app and whose scope goes beyond a single type. Therefore it would make sense to put it in a separate file & outside of the scope of a parent type. Properties belonging to a type always have to be defined within the scope of a type & should ideally be defined where the type itself is defined (same file). Sometimes we use separate files for longer extensions and protocol implementations where computed properties or other elements are moved to different files. So computed properties such as |
Beta Was this translation helpful? Give feedback.
Hi @kkarenvoo05,
Thank you for asking a question here on GitHub!
I think there might be a confusion between nested types (see Apple Swift Documentation) and type properties (great article provide an overview of what's possible in Swift).
Nested types are a great way to structure types that are very closely bound to each other and where a type-based name scoping makes sense (such as the cards example in the documentation). The feedback for assignment 1 was probably targeted to a nested type that would make sense to be used across the app and whose scope goes beyond a single type. Therefore it would make sense to put it in a separate file & outside of the scope of a parent type.
Properties …