When I saw the header, I immediately wanted to press "dislike".
Is the problem being addressed significant enough to warrant a change to
Swift?
I'm not 100% sure, but inclined to say "yes".
Does this proposal fit well with the feel and direction of Swift?
No. Protocols, which have been greatly enhanced in Swift 2.0, already
replaced inheritance in many places.
If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?
I primarily associate Swift protocols with Java interfaces, which also got
`default` methods. Having "played" with Java in the last few years, I agree
that usage of interfaces leads to overall better code style than abstract
classes. I have also used Ruby (and Rails), where modules are actually
mixins. Their usage proved simple and straightforward.
How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
I have followed the discussion and have a position based mainly on
experience with other languages.
Is this really becoming an ideological battleground of protocols oriented programming vs inheritance? We are not discussing how to hold back POP unless making inheritance work better is a threat to it.
···
Sent from my iPhone
On 27 Feb 2016, at 10:16, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:
> What is your evaluation of the proposal?
When I saw the header, I immediately wanted to press "dislike".
> Is the problem being addressed significant enough to warrant a change to Swift?
I'm not 100% sure, but inclined to say "yes".
> Does this proposal fit well with the feel and direction of Swift?
No. Protocols, which have been greatly enhanced in Swift 2.0, already replaced inheritance in many places.
> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I primarily associate Swift protocols with Java interfaces, which also got `default` methods. Having "played" with Java in the last few years, I agree that usage of interfaces leads to overall better code style than abstract classes. I have also used Ruby (and Rails), where modules are actually mixins. Their usage proved simple and straightforward.
> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I have followed the discussion and have a position based mainly on experience with other languages.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
If both mixins and abstract classes are implemented, we get duplicated
functionality, just with different names. Is it right?
And I guess I'm biased. I rely on Swift team to decide, maybe include none
or both.