> On Aug 2, 2017, at 6:15 PM, Taylor Swift <[email protected]> wrote: > > I agree with this, extensions on types defined in the same file are generally > silly, and default implementations belong in the protocol body. I don’t agree > with certain style guides prescription of same-file extensions; they should > only be used to hide protocol conformances that are “unimportant” to the > functionality of the type. In practice this means only conformances like > CustomStringConvertible and CustomDebugStringConvertible live in extensions. > > If you want to group related methods, use linebreaks and whitespace for that. > Don’t split up the type braces since that messes up the whole > one-set-of-braces == one type definition visual rule. > > The only time it ever makes sense to extend a non concrete type that you own > is when adding conditional default implementations. Having to extend a bare > protocol is the product of a language limitation.
Take a look at my replies to Tino Heth about code locality and the rest... > On Wed, Aug 2, 2017 at 6:26 AM, Tino Heth via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> That would work as well, but it has the downside of forcing a potentially >> huge number of methods to be implemented in a single place, reducing the >> readability as opposed to packing them into semantically related groups in >> the form of extensions. > > I really don't get why people are so obsessed with same-file extensions: > They are recommended in style guides, influencers blog about them, and they > motivated a ridiculous complex change in the access rights system. Yet I > haven't seen any evidence that they offer real benefit. > Extensions are great for adding useful helpers to existing types, and still > allow you to selectively expose details of your own classes — but most people > seem to ignore those options and focus on something can be done better with > plain old comments. > [sorry for the rant — but I think a critical look at extensions is long > overdue: I rarely see someone questioning their role, so basically, we are > making important decisions based on pure superstition] > > A protocol itself is already a vehicle to group related methods, and if you > have a huge entity, it doesn't get better just because you split it and hide > its complexity. > >> Also, please include the original message for reference purposes. > [hopes Discourse will happen soon ;-) ] > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
