On Wed, Aug 2, 2017 at 1:09 PM, Gor Gyolchanyan via swift-evolution < [email protected]> 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. -- Víctor Pimentel
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
