> On Aug 2, 2017, at 2:20 PM, Víctor Pimentel Rodríguez <vpimen...@tuenti.com> > wrote: > > On Wed, Aug 2, 2017 at 1:09 PM, Gor Gyolchanyan via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> and if you have a huge entity, it doesn't get better just because you split >> it and hide its complexity. > > Splitting and hiding complexity is by far the only reasonable way of dealing > with huge entities. If the entity gains too much responsibility, it's > probably a good idea to split it into several smaller entities. If the entity > contains a large amount of accidental complexity that solely serves the > purpose of enabling a select set of intended features, then it's probably a > good idea to hide the accidental complexity away from users of the entity. > > In fact, that's exactly why I always wished that protocols could get private > requirements that are there solely for use in protocol extensions and are > otherwise hidden from existence. I haven't talked about this in detail > because I don't see a reasonable way of implementing it yet. > > +1, although most times I wanted this because of the impossibility of > defining stored attributes in protocol extensions, let alone private stored > attributes.
Considering how private access level works within file scope because of code visibility guarantees (the compiler is guaranteed to be able to see both the type and the extension at the same time), the same could be said about stored properties in extension within file scope. Since bot the type and the extension are defined in the same file, there's no way for the type to get improperly laid out, since all stored properties are still visible at the same time. I wonder what it would take to implement this... > -- > Víctor Pimentel
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
