My preference would be around features to aggregate functionality, or to provide proper mixing.
1. One simpler feature would be a way to indicate your implementation of a protocol is via a property, and that calls should be forwarded. 2. More complex mixin behavior would include the included feature basically requesting a protocol as well, as a sort of language-level delegate. Compiler support means this can be done with value types, and that the implementations can be optimized/inlined. Partial classes can solve some of these problems, but without a contract it can be difficult to manage the spaghetti nest of data and responsibilities. It also doesn’t allow for either part to be reusable across multiple implementations (except through class inheritance). Partial classes in C# always seemed to exist specifically to combine authored and generated code without requiring a subclassing relationship. -DW > On Nov 8, 2017, at 11:44 AM, Adam Kemp via swift-evolution > <swift-evolution@swift.org> wrote: > > That is a legitimate concern, but massive view controllers is a problem that > already exists. The kind of person who would use partial classes to split up > a giant view controller would probably also use extensions and just throw all > of the fields in the main file. People do that today with both Objective-C > and Swift. Partial classes would only make it marginally easier to implement > the bad designs that people are already doing. So I do think it’s a > legitimate concern, but I also think the benefits outweigh those costs. > >> On Nov 8, 2017, at 2:54 AM, Benjamin G <benjamin.garrig...@gmail.com> wrote: >> >> All your use cases make perfect sense, however i see one potential issue >> with this "pattern" : >> >> I've seen a LOT of iOS developers (some juniors, some not) ending up with >> monstruous UIViewControllers, and it has happened almost since the very >> beginning of iOS development. Because of their lack of understanding of the >> MVC pattern, they completely under estimate either the model or the view >> layer and put too many things in their VC. >> >> Now this pattern would give them the illusion that they're working in a sane >> architecture and that they've decomposed the problem correctly, but in fact >> were not. The fact that extension wouldn't let you add variable makes it >> harder to conceal the problem, but with "continuations" i can see no limit. >> >> What do you think ? > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
