[swift-evolution-announce] [Review] SE-0026 Abstract classes and methods


(Anton Zhilin) #1

It would be interesting to know your opinion on "mixins" proposal. Do you
need some kind of "abstract classes for structs", perhaps with multiple
inheritance, or you find that more elegant architectual solutions to
problems can be found, without partially implemented constructs?
https://gist.github.com/Anton3/f0550922c1be0fc5447c


(Anton Zhilin) #2

My GMail keeps breaking threads. I wrote this in reply to this post of
Matthew Johnson:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011351.html

···

2016-02-28 19:50 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com>:

It would be interesting to know your opinion on "mixins" proposal. Do you
need some kind of "abstract classes for structs", perhaps with multiple
inheritance, or you find that more elegant architectual solutions to
problems can be found, without partially implemented constructs?
https://gist.github.com/Anton3/f0550922c1be0fc5447c


(Trent Nadeau) #3

      • What is your evaluation of the proposal?

-1. I would prefer something like mixins that could work without
inheritance and would thus also work with value types.

      • Is the problem being addressed significant enough to warrant a

change to Swift?
Yes, although I don't think abstract classes that force inheritance and
only work for classes is the answer.

      • Does this proposal fit well with the feel and direction of Swift?

No.

      • If you have used other languages or libraries with a similar

feature, how do you feel that this proposal compares to those?
My opinion is based on other languages I've used that have better ways to
handle this (Ruby, Python, D) as well as the downsides I've seen with
abstract classes in Java and C++.

      • How much effort did you put into your review? A glance, a quick

reading, or an in-depth study?
I've followed the various threads on this topic that have come up since
Swift was open-sourced.

···

On Sun, Feb 28, 2016 at 12:02 PM, Антон Жилин <swift-evolution@swift.org> wrote:

My GMail keeps breaking threads. I wrote this in reply to this post of
Matthew Johnson:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011351.html

2016-02-28 19:50 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com>:

It would be interesting to know your opinion on "mixins" proposal. Do you
need some kind of "abstract classes for structs", perhaps with multiple
inheritance, or you find that more elegant architectual solutions to
problems can be found, without partially implemented constructs?
https://gist.github.com/Anton3/f0550922c1be0fc5447c

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau


(Goffredo Marocchi) #4

So far while pushing for protocol oriented programming as one of Swift's distinctive features, the Swift team (or at least Chris Lattner) stated that inheritance is not a patter which is bad per se, it is a pattern which has its uses and it is fully supported by Swift just as much as other patterns Swift makes available. In my opinion of you have a feature, this feature should not fight with a hand tied behind its back: the "if you do it, do it well" approach :).

Answers like this seem to be the next best thing from asking to remove inheritance outright or to limit it more. Improving protocols, improving functional programming support, etc... all of that is orthogonal to improving OOP through class inheritance.
Support for abstract classes does not force people to use inheritance. Instead of doc using energies pushing down proposals that advocate for improving class based inheritance, I see energy better spent in making proposals that improve protocols unless they get filled by inheritance die hard afraid of the success of protocols meaning a death sentence for inheritance :).

···

Sent from my iPhone

On 28 Feb 2016, at 17:11, Trent Nadeau via swift-evolution <swift-evolution@swift.org> wrote:

> • What is your evaluation of the proposal?
-1. I would prefer something like mixins that could work without inheritance and would thus also work with value types.

> • Is the problem being addressed significant enough to warrant a change to Swift?
Yes, although I don't think abstract classes that force inheritance and only work for classes is the answer.

> • Does this proposal fit well with the feel and direction of Swift?
No.

> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
My opinion is based on other languages I've used that have better ways to handle this (Ruby, Python, D) as well as the downsides I've seen with abstract classes in Java and C++.

> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I've followed the various threads on this topic that have come up since Swift was open-sourced.

On Sun, Feb 28, 2016 at 12:02 PM, Антон Жилин <swift-evolution@swift.org> wrote:
My GMail keeps breaking threads. I wrote this in reply to this post of Matthew Johnson:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011351.html

2016-02-28 19:50 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com>:

It would be interesting to know your opinion on "mixins" proposal. Do you need some kind of "abstract classes for structs", perhaps with multiple inheritance, or you find that more elegant architectual solutions to problems can be found, without partially implemented constructs?
https://gist.github.com/Anton3/f0550922c1be0fc5447c

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Anton Zhilin) #5

Some more ideas. I do not necessary look at them as arguments "for" or
"against", and additionally I'm biased, as I've already said.

While there are many use cases for mixins and multiple inheritance, in many
cases there is a superclass which is clearly predominant, almost like the
classical animals, cats and dogs.
Classes are a bit simpler to grasp for users of C++ and similar languages.
My mixins proposal currently has issues regarding multiple inheritance.
(Does it?)

The fact that classes and mixins have duplicated functionality, still bugs
me.
I also prefer "pure" approach, where everything is a struct unless it needs
class-only features - deinit, for example. It is my personal opinion.

···

2016-02-28 20:28 GMT+03:00 Goffredo Marocchi <panajev@gmail.com>:

So far while pushing for protocol oriented programming as one of Swift's
distinctive features, the Swift team (or at least Chris Lattner) stated
that inheritance is not a patter which is bad per se, it is a pattern which
has its uses and it is fully supported by Swift just as much as other
patterns Swift makes available. In my opinion of you have a feature, this
feature should not fight with a hand tied behind its back: the "if you do
it, do it well" approach :).

Answers like this seem to be the next best thing from asking to remove
inheritance outright or to limit it more. Improving protocols, improving
functional programming support, etc... all of that is orthogonal to
improving OOP through class inheritance.
Support for abstract classes does not force people to use inheritance.
Instead of doc using energies pushing down proposals that advocate for
improving class based inheritance, I see energy better spent in making
proposals that improve protocols unless they get filled by inheritance die
hard afraid of the success of protocols meaning a death sentence for
inheritance :).

Sent from my iPhone

On 28 Feb 2016, at 17:11, Trent Nadeau via swift-evolution < > swift-evolution@swift.org> wrote:

> • What is your evaluation of the proposal?
-1. I would prefer something like mixins that could work without
inheritance and would thus also work with value types.

> • Is the problem being addressed significant enough to warrant a
change to Swift?
Yes, although I don't think abstract classes that force inheritance and
only work for classes is the answer.

> • Does this proposal fit well with the feel and direction of Swift?
No.

> • If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
My opinion is based on other languages I've used that have better ways to
handle this (Ruby, Python, D) as well as the downsides I've seen with
abstract classes in Java and C++.

> • How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
I've followed the various threads on this topic that have come up since
Swift was open-sourced.

On Sun, Feb 28, 2016 at 12:02 PM, Антон Жилин <swift-evolution@swift.org> > wrote:

My GMail keeps breaking threads. I wrote this in reply to this post of
Matthew Johnson:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011351.html

2016-02-28 19:50 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com>:

It would be interesting to know your opinion on "mixins" proposal. Do
you need some kind of "abstract classes for structs", perhaps with multiple
inheritance, or you find that more elegant architectual solutions to
problems can be found, without partially implemented constructs?
https://gist.github.com/Anton3/f0550922c1be0fc5447c

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Owens II) #6

Building the functionality into abstract classes artificially limits the context for the problem though.

For example, there are cases where it's desirable for a protocol to be able to specify the storage mechanism for a property. If a protocol gains the ability to do that, that's just one benefit that abstract classes provide that is no longer necessary.

-David

···

On Feb 28, 2016, at 9:28 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

So far while pushing for protocol oriented programming as one of Swift's distinctive features, the Swift team (or at least Chris Lattner) stated that inheritance is not a patter which is bad per se, it is a pattern which has its uses and it is fully supported by Swift just as much as other patterns Swift makes available. In my opinion of you have a feature, this feature should not fight with a hand tied behind its back: the "if you do it, do it well" approach :).

Answers like this seem to be the next best thing from asking to remove inheritance outright or to limit it more. Improving protocols, improving functional programming support, etc... all of that is orthogonal to improving OOP through class inheritance.
Support for abstract classes does not force people to use inheritance. Instead of doc using energies pushing down proposals that advocate for improving class based inheritance, I see energy better spent in making proposals that improve protocols unless they get filled by inheritance die hard afraid of the success of protocols meaning a death sentence for inheritance :).

Sent from my iPhone

On 28 Feb 2016, at 17:11, Trent Nadeau via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> • What is your evaluation of the proposal?
-1. I would prefer something like mixins that could work without inheritance and would thus also work with value types.

> • Is the problem being addressed significant enough to warrant a change to Swift?
Yes, although I don't think abstract classes that force inheritance and only work for classes is the answer.

> • Does this proposal fit well with the feel and direction of Swift?
No.

> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
My opinion is based on other languages I've used that have better ways to handle this (Ruby, Python, D) as well as the downsides I've seen with abstract classes in Java and C++.

> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I've followed the various threads on this topic that have come up since Swift was open-sourced.

On Sun, Feb 28, 2016 at 12:02 PM, Антон Жилин <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
My GMail keeps breaking threads. I wrote this in reply to this post of Matthew Johnson:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011351.html

2016-02-28 19:50 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com <mailto:antonyzhilin@gmail.com>>:
It would be interesting to know your opinion on "mixins" proposal. Do you need some kind of "abstract classes for structs", perhaps with multiple inheritance, or you find that more elegant architectual solutions to problems can be found, without partially implemented constructs?
https://gist.github.com/Anton3/f0550922c1be0fc5447c

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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


(David Scrève) #7

Interesting approach…here, we prefer class approach to struct for 2 majors reasons :
1 - We usually use OOP and class is a common mechanism for us
2 - We reserve struct for small object because struct are value type and passing struct in parameter may be stack and time consuming.

Usually we design architecture of our product as something which is language independ. So the quality of a language is its ability to easily implement architecture concept that we’ve designed, but we thing that a language should not (or should have the less) impact the architecture that has been designed.

···

Le 28 févr. 2016 à 19:25, Антон Жилин via swift-evolution <swift-evolution@swift.org> a écrit :

Some more ideas. I do not necessary look at them as arguments "for" or "against", and additionally I'm biased, as I've already said.

While there are many use cases for mixins and multiple inheritance, in many cases there is a superclass which is clearly predominant, almost like the classical animals, cats and dogs.
Classes are a bit simpler to grasp for users of C++ and similar languages.
My mixins proposal currently has issues regarding multiple inheritance. (Does it?)

The fact that classes and mixins have duplicated functionality, still bugs me.
I also prefer "pure" approach, where everything is a struct unless it needs class-only features - deinit, for example. It is my personal opinion.

2016-02-28 20:28 GMT+03:00 Goffredo Marocchi <panajev@gmail.com <mailto:panajev@gmail.com>>:
So far while pushing for protocol oriented programming as one of Swift's distinctive features, the Swift team (or at least Chris Lattner) stated that inheritance is not a patter which is bad per se, it is a pattern which has its uses and it is fully supported by Swift just as much as other patterns Swift makes available. In my opinion of you have a feature, this feature should not fight with a hand tied behind its back: the "if you do it, do it well" approach :).

Answers like this seem to be the next best thing from asking to remove inheritance outright or to limit it more. Improving protocols, improving functional programming support, etc... all of that is orthogonal to improving OOP through class inheritance.
Support for abstract classes does not force people to use inheritance. Instead of doc using energies pushing down proposals that advocate for improving class based inheritance, I see energy better spent in making proposals that improve protocols unless they get filled by inheritance die hard afraid of the success of protocols meaning a death sentence for inheritance :).

Sent from my iPhone

On 28 Feb 2016, at 17:11, Trent Nadeau via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> • What is your evaluation of the proposal?
-1. I would prefer something like mixins that could work without inheritance and would thus also work with value types.

> • Is the problem being addressed significant enough to warrant a change to Swift?
Yes, although I don't think abstract classes that force inheritance and only work for classes is the answer.

> • Does this proposal fit well with the feel and direction of Swift?
No.

> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
My opinion is based on other languages I've used that have better ways to handle this (Ruby, Python, D) as well as the downsides I've seen with abstract classes in Java and C++.

> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I've followed the various threads on this topic that have come up since Swift was open-sourced.

On Sun, Feb 28, 2016 at 12:02 PM, Антон Жилин <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
My GMail keeps breaking threads. I wrote this in reply to this post of Matthew Johnson:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011351.html

2016-02-28 19:50 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com <mailto:antonyzhilin@gmail.com>>:
It would be interesting to know your opinion on "mixins" proposal. Do you need some kind of "abstract classes for structs", perhaps with multiple inheritance, or you find that more elegant architectual solutions to problems can be found, without partially implemented constructs?
https://gist.github.com/Anton3/f0550922c1be0fc5447c

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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


(Goffredo Marocchi) #8

You may want people to have the flexibility of using either of the two approaches :).

···

Sent from my iPhone

On 29 Feb 2016, at 17:16, David Owens II <david@owensd.io> wrote:

Building the functionality into abstract classes artificially limits the context for the problem though.

For example, there are cases where it's desirable for a protocol to be able to specify the storage mechanism for a property. If a protocol gains the ability to do that, that's just one benefit that abstract classes provide that is no longer necessary.

-David

On Feb 28, 2016, at 9:28 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

So far while pushing for protocol oriented programming as one of Swift's distinctive features, the Swift team (or at least Chris Lattner) stated that inheritance is not a patter which is bad per se, it is a pattern which has its uses and it is fully supported by Swift just as much as other patterns Swift makes available. In my opinion of you have a feature, this feature should not fight with a hand tied behind its back: the "if you do it, do it well" approach :).

Answers like this seem to be the next best thing from asking to remove inheritance outright or to limit it more. Improving protocols, improving functional programming support, etc... all of that is orthogonal to improving OOP through class inheritance.
Support for abstract classes does not force people to use inheritance. Instead of doc using energies pushing down proposals that advocate for improving class based inheritance, I see energy better spent in making proposals that improve protocols unless they get filled by inheritance die hard afraid of the success of protocols meaning a death sentence for inheritance :).

Sent from my iPhone

On 28 Feb 2016, at 17:11, Trent Nadeau via swift-evolution <swift-evolution@swift.org> wrote:

> • What is your evaluation of the proposal?
-1. I would prefer something like mixins that could work without inheritance and would thus also work with value types.

> • Is the problem being addressed significant enough to warrant a change to Swift?
Yes, although I don't think abstract classes that force inheritance and only work for classes is the answer.

> • Does this proposal fit well with the feel and direction of Swift?
No.

> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
My opinion is based on other languages I've used that have better ways to handle this (Ruby, Python, D) as well as the downsides I've seen with abstract classes in Java and C++.

> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I've followed the various threads on this topic that have come up since Swift was open-sourced.

On Sun, Feb 28, 2016 at 12:02 PM, Антон Жилин <swift-evolution@swift.org> wrote:
My GMail keeps breaking threads. I wrote this in reply to this post of Matthew Johnson:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011351.html

2016-02-28 19:50 GMT+03:00 Антон Жилин <antonyzhilin@gmail.com>:

It would be interesting to know your opinion on "mixins" proposal. Do you need some kind of "abstract classes for structs", perhaps with multiple inheritance, or you find that more elegant architectual solutions to problems can be found, without partially implemented constructs?
https://gist.github.com/Anton3/f0550922c1be0fc5447c

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau
_______________________________________________
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