Consider these two alternative ways of writing the same code:
https://gist.github.com/technogen-gg/17b6d5e13c13080850dceda28cfe1caa
<https://gist.github.com/technogen-gg/17b6d5e13c13080850dceda28cfe1caa>
> On Aug 2, 2017, at 6:57 PM, Taylor Swift <kelvin1...@gmail.com> wrote:
>
> I don’t understand how extensions help with code locality. It’s literally a
> matter of curly braces. I already glue the extension block to the bottom } of
> the protocol block anyway by omitting the empty linebreak.
>
> protocol Protocol
> {
> func default_function()
> }
> extension Protocol
> {
> func default_function()
> {
> }
> }
>
> as opposed to
>
> protocol Protocol
> {
> func default_function()
> {
> }
> }
>
> I would very much appreciate not having to retype Protocol and
> default_function() over and over. The whole cult-of-same-file-extensions
> seems to be people refusing to let go of old C++ habits. Have you noticed
> that nowhere else in Swift is there a concept of separating type declarations
> from type definitions? That’s because people managed to figure out that
> typing the same words over and over again doesn’t actually keep code neater
> at all.
>
> On Wed, Aug 2, 2017 at 11:27 AM, Gor Gyolchanyan
> <gor.f.gyolchan...@icloud.com <mailto:gor.f.gyolchan...@icloud.com>> wrote:
>
>> On Aug 2, 2017, at 6:15 PM, Taylor Swift <kelvin1...@gmail.com
>> <mailto:kelvin1...@gmail.com>> 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
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
