[swift-evolution] [swift-evolution-announce] [Review] SE-0026 Abstract classes and methods
Gwendal Roué
gwendal.roue at gmail.com
Tue Mar 1 00:54:05 CST 2016
> Le 1 mars 2016 à 07:08, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> a écrit :
>
> I'm missing an important feature in your list: being able to declare protocol members with access scopes different from that of the protocol, i.e. private or internal in a public protocol.
> This is a very important requirement for something like template methods.
>
> Another important feature quite related to that is a "protected" scope.
>
> […]
>
>> * No problems with private abstract members of public types; all protocol requirements are already as public as the protocol itself.
>
> That is a marked disadvantage which prohibits defining partial behavior which is filled in by concrete types!
> If protocols should remain like that then that alone is a decisive argument for adding abstract classes.
>
> -Thorsten
I 100% support this point. Today all declarations in a protocol are as public as the protocol itself. Only "abstract classes", as known from languages that support this concept, are able to hide some implementation details.
As long as protocols keep "flat" access control, there will be a need for abstract classes, the ready-made concept that already provides data hiding and encapsulation.
Gwendal
More information about the swift-evolution
mailing list