Currently I have in a private framework a class named
`AccountAuthorizationController` with subclasses like
`OAuthAccountAuthorizationController`,
`OAuth2AccountAuthorizationController` and
`WebFormAccountAuthorizationController` and so on.
In the root "abstract" class I have methods without implementation where I
have to use `fatalError()` to ensure that they will never been called. I
cannot prevent the framework user to instantiate the
`AccountAuthorizationController`, however.
Look that this is only one example. I have other cases as well when I'd
like to have abstract classes and abstract methods.
I know that structs and protocols are "elegant, simple and powerful" (as
they seem to be all new frameworks and languages that pop up every day on
the Internet) and the arguments in favor of composition rather than
inheritance. But I still would like to take advantage of the decades of
available knowledge in object orientation in my projects.
+1 for abstract classes and abstract methods.
-Van
···
On Fri, Feb 26, 2016 at 12:46 PM, Evan Maloney via swift-evolution < swift-evolution@swift.org> wrote:
> Well not exactly, if you want the same behaviors in subclasses of
UIViewController and UITableViewController :
> - with protocols + extensions, you write in once and apply it to each of
your subclasses
> - with abstract classes you have to write 2 abstract classes, one for
direct UIViewController subclasses, one for UITableViewController subclasses
That's a problem with class hierarchies in general, not with abstract
classes.
You can use the same argument to call for the removal of classes from
Swift, which is why I think the fundamental question is, are classes
intended to be first-class citizens in Swift?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
> > The other problem with the protocol-based solution is that it leads to conceptual leakage. The protocol you need to declare lives outside the class(es) that need it.
> >
> > The ActivityViewControlling protocol is now available universally, even though it's interface is only relevant to a certain portion the class hierarchy.
There wouldnât really be a conceptual leakage. If we treat the protocol as a replacement for the abstract class, we see that both implementations amount to pretty much the same thing.
If before we wanted an abstract class MyController, subclassed as MyControllerA and MyControllerB, we could âsubstituteâ it (using Brentâs suggestions) with MyProtocol.
MyProtocol would have the same (universal) scope as MyController, so users could reference the generic MyProtocol at will (and not have to specify individual subclasses).
In a similar manner, we donât think of MyControllerA and MyControllerB so much as subclasses of my controller anymore, but as implementations of MyProtocol. If we ever âforgetâ to add protocol conformance, the issue would be instantly found at compile time, since the new subclasses would be incompatible with all references to MyProtocol in our code and would also lack the possible extensions provided by MyProtocol.
Well not exactly, if you want the same behaviors in subclasses of UIViewController and UITableViewController :
- with protocols + extensions, you write in once and apply it to each of your subclasses
- with abstract classes you have to write 2 abstract classes, one for direct UIViewController subclasses, one for UITableViewController subclasses
That's a problem with class hierarchies in general, not with abstract classes.
Yes, but that's not my point, I'm just answering "what's the difference"
You can use the same argument to call for the removal of classes from Swift,
It's going a bit far, inheritance has its own advantages in other situations.
which is why I think the fundamental question is, are classes intended to be first-class citizens in Swift?
Good question. I would think so, but only as much as structs, enum and protocols.
On Fri, Feb 26, 2016, at 10:38 PM, Vanderlei Martinelli via swift-evolution wrote:
I know that structs and protocols are "elegant, simple and powerful"
(as they seem to be all new frameworks and languages that pop up every
day on the Internet) and the arguments in favor of composition rather
than inheritance. But I still would like to take advantage of the
decades of available knowledge in object orientation in my projects.
It seems like having a protocol restricted to instances of âAccountAuthorizationControllerâ (as Brent suggested) would solve your problem, wouldnât it?
You could just add all method declarations that are supposed to be abstract to that protocol instead, and then make sure your subclasses implement the protocol - which means the compiler forces them to implement the abstract methods.
···
Currently I have in a private framework a class named `AccountAuthorizationController` with subclasses like `OAuthAccountAuthorizationController`, `OAuth2AccountAuthorizationController` and `WebFormAccountAuthorizationController` and so on.
In the root "abstract" class I have methods without implementation where I have to use `fatalError()` to ensure that they will never been called. I cannot prevent the framework user to instantiate the `AccountAuthorizationController`, however.
Look that this is only one example. I have other cases as well when I'd like to have abstract classes and abstract methods.
I know that structs and protocols are "elegant, simple and powerful" (as they seem to be all new frameworks and languages that pop up every day on the Internet) and the argumentsin favor of composition rather than inheritance. But I still would like to take advantage of the decades of available knowledge in object orientation in my projects.
+1 for abstract classes and abstract methods.
-Van
On Fri, Feb 26, 2016 at 12:46 PM, Evan Maloney via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
> >Well not exactly, if you want the same behaviors in subclasses of UIViewController and UITableViewController :
> >- with protocols + extensions, you write in once and apply it to each of your subclasses
> >- with abstract classes you have to write 2 abstract classes, one for direct UIViewController subclasses, one for UITableViewController subclasses
>
> That's a problem with class hierarchies in general, not with abstract classes.
>
> You can use the same argument to call for the removal of classes from Swift, which is why I think the fundamental question is, are classes intended to be first-class citizens in Swift?
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> https://lists.swift.org/mailman/listinfo/swift-evolution
Also abstract class also allow override methods and create properties (very
useful for IBOutLets) which protocol does not. +1
···
On Fri, Feb 26, 2016 at 1:48 PM plx via swift-evolution < swift-evolution@swift.org> wrote:
A quick remark:
Although it is definitely a *work-around*, you can at present use the
following technique:
protocol ActivityViewControlling {
// the name doesnât have to be this long, but you may want to avoid
// accidental naming collisions:
func viewControllerForActivityViewControlling() -> UIViewController
func retrieveText() -> String
}
extension ActivityViewControlling where Self:UIViewController {
âŠas a clunky but functional replacement for the capability to declare
`protocol ActivityViewControlling: UIViewController`.
Iâd still like the ability to constrain protocols in that way, but the
above makes it harder to âaccidentally, uselessly conformâ.
> On Feb 25, 2016, at 7:48 PM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote:
>
>> That way would work if you forced every initializer in the class to
accept a parameter representing each and every function you want to declare
abstract. And it just gets messier from there, since if you wanted to do
the same for get/set abstract properties, you'd need to model both the
getter and setter separately, so for those you have 2 parameters.
>>
>> If you have 2 abstract functions and 3 abstract get/set properties you
want to model, you've just added 8 new parameters that you must pass to
each one of your class's initializers.
>
> Of course, which is why if you had eight override points, you would put
them in one delegate protocol and pass in a single delegate instead. Your
example had one override point, so it would be reasonable to use one
closure, but even two override points would tilt the scales heavily towards
using a delegate, and eight would be right out.
>
>> It's one of the reasons we don't use Interface Builder with our Swift
codebase. IB is an end-run around many of the compile-time safety features
that make Swift great.
>
>
> If you're not using IB, then there's no reason not to use a custom
initializer that takes the delegate as a parameter, and you therefore would
not need to worry about the delegate being uninitialized.
>
>> Now that I think about it, what I'm talking about is pretty much the
same behavior as the 'required' keyword with classes, but for things that
aren't initializers.
>
>
> The `required` keyword is something quite differentâit states that all
subtypes, at any degree of separation, must include this member. It only
makes sense for initializers, because all other members are implicitly
inherited and therefore subtypes always include them.
>
> In other words, *all* members in Swift are required except for
initializers without the `required` keyword, so the `required` keyword
doesn't really make any sense here.
>
>> The other problem with the protocol-based solution is that it leads to
conceptual leakage. The protocol you need to declare lives outside the
class(es) that need it.
>>
>> The ActivityViewControlling protocol is now available universally, even
though it's interface is only relevant to a certain portion the class
hierarchy.
>
> I'm not sure I understand what you mean, but I *think* you're
complaining that you can apply ActivityViewControlling to something that's
not a UIViewController. I do agree that's a problem, which is why I
suggested we should allow protocols to require a particular superclass:
>
> protocol ActivityViewControlling: UIViewController {
> func retrieveText() -> String
> }
> extension ActivityViewControlling {
> ...
> }
> class MyActivityViewController: ActivityViewControlling {
> func retrieveText() -> String { ... }
> }
>
> The requirement would not constrain conforming types quite as tightly as
an abstract class wouldâit would allow you to conform, say, a
UITableViewController subclass to ActivityViewControlling. However, there
are almost certainly cases where that would be a benefit, not a detriment,
so that might be a net win even if it's not quite as good for this
particular use case.
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
Actually, I donât understand the opposite that is made between Extension (that is ported by POP) and Specialization (ported by inheritance).
Many OOP missed extension concept and developer mis-use inheritance to make extensionâŠbut having both concept allow to use properly extension and inheritance.
If you make inheritance not fully operational, Swift will have exactly the same problem : people will try to make specialization with extension (using POP) whereas they should use inheritance.
In addition, I thing adding stored property to protocol create a new question : Why using classes if protocols provide the same feature ?
Well not exactly, if you want the same behaviors in subclasses of UIViewController and UITableViewController :
- with protocols + extensions, you write in once and apply it to each of your subclasses
- with abstract classes you have to write 2 abstract classes, one for direct UIViewController subclasses, one for UITableViewController subclasses
That's a problem with class hierarchies in general, not with abstract classes.
Yes, but that's not my point, I'm just answering "what's the difference"
You can use the same argument to call for the removal of classes from Swift,
It's going a bit far, inheritance has its own advantages in other situations.
which is why I think the fundamental question is, are classes intended to be first-class citizens in Swift?
Good question. I would think so, but only as much as structs, enum and protocols.
Thank you. This is a good suggestion, but does not fit the case. The `
AccountAuthorizationController` is an "abstract" class but it is not a
"dumb" class. It store data, reference to injected class instances and do
other important things. If I implement all of this as protocols I have to
duplicate code here and there. I know I can use protocol extensions to
provide default implementations. Even so, I'll have duplicate code.
Do not take me wrong, I really like protocols and structs and I understand
how to use them, but it seems that many of us believe that the is something
wrong with classes and the protocol/struct is the new Holy Grail. I
disagree. New possibilites and new way to do things are always welcome,
mainly if they are solid and consistent and really solves the
problem intended to be solved.
I also understand that the Swift team does not want to introduce any new
keywords to the language. To tell the truth I think I need to read again
all the information on Swift. I thought the Swift would be one thing, but
looks like it will be another. It is likely that the wrong one is me.
Provide ways to create abstract classes and abstract methods is not a
"keystroke saver". It is one of many concepts involved in OOP, IMHO.
-Van
···
On Fri, Feb 26, 2016 at 3:45 PM, Vinicius Vendramini <vinivendra@gmail.com> wrote:
It seems like having a protocol restricted to instances of âAccountAuthorizationControllerâ
(as Brent suggested) would solve your problem, wouldnât it?
You could just add all method declarations that are supposed to be
abstract to that protocol instead, and then make sure your subclasses
implement the protocol - which means the compiler forces them to implement
the abstract methods.
> Currently I have in a private framework a class named
`AccountAuthorizationController` with subclasses like
`OAuthAccountAuthorizationController`,
`OAuth2AccountAuthorizationController` and
`WebFormAccountAuthorizationController` and so on.
>
> In the root "abstract" class I have methods without implementation where
I have to use `fatalError()` to ensure that they will never been called. I
cannot prevent the framework user to instantiate the
`AccountAuthorizationController`, however.
>
> Look that this is only one example. I have other cases as well when I'd
like to have abstract classes and abstract methods.
>
> I know that structs and protocols are "elegant, simple and powerful" (as
they seem to be all new frameworks and languages that pop up every day on
the Internet) and the argumentsin favor of composition rather than
inheritance. But I still would like to take advantage of the decades of
available knowledge in object orientation in my projects.
>
> +1 for abstract classes and abstract methods.
>
> -Van
>
> On Fri, Feb 26, 2016 at 12:46 PM, Evan Maloney via swift-evolution< > swift-evolution@swift.org(mailto:swift-evolution@swift.org > <swift-evolution@swift.org>)>wrote:
> > >Well not exactly, if you want the same behaviors in subclasses of
UIViewController and UITableViewController :
> > >- with protocols + extensions, you write in once and apply it to each
of your subclasses
> > >- with abstract classes you have to write 2 abstract classes, one for
direct UIViewController subclasses, one for UITableViewController subclasses
> >
> > That's a problem with class hierarchies in general, not with abstract
classes.
> >
> > You can use the same argument to call for the removal of classes from
Swift, which is why I think the fundamental question is, are classes
intended to be first-class citizens in Swift?
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto:swift-evolution@swift.org
<swift-evolution@swift.org>)
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
Actually, I donât understand the opposite that is made between Extension
(that is ported by POP) and Specialization (ported by inheritance).
Many OOP missed extension concept and developer mis-use inheritance to
make extensionâŠbut having both concept allow to use properly extension and
inheritance.
If you make inheritance not fully operational, Swift will have exactly the
same problem : people will try to make specialization with extension (using
POP) whereas they should use inheritance.
In addition, I thing adding stored property to protocol create a new
question : Why using classes if protocols provide the same feature ?
Protocols are not concrete types, at some point you will choose if will use
a *reference type* or a *value type* to implement this protocol, and then,
inherit this "default" properties.
···
Em seg, 29 de fev de 2016 Ă s 17:20, David ScrĂšve <swift-evolution@swift.org> escreveu:
I see, that seems about right. If we have a bas class that is not dumb, and especially if that base class needs to call abstract methods in its existing methods, I donât think that solution would be enough.
I would still rather have a solution that extends protocols than one that relies specifically on classes, it seems to me that doing so would make the resulting functionality more generic (for instance, it might be possible to use it with structs as well as classes). However, Iâm starting to agree that this is an important language feature indeed, since I canât think of any better (or even equivalent) way of solving the example you showed.
In any case, I think the current proposal might be a bit too complex. Having to specify which property accessors are abstract (get, set, willSet or didSet), for instance, is going too far IMO. In its current form I do not support it (so -1 for me), but I could get behind the same idea using a simpler design.
···
On Feb 26, 2016, at 2:20 PM, Vanderlei Martinelli <vmartinelli@alecrim.com> wrote:
Thank you. This is a good suggestion, but does not fit the case. The `AccountAuthorizationController` is an "abstract" class but it is not a "dumb" class. It store data, reference to injected class instances and do other important things. If I implement all of this as protocols I have to duplicate code here and there. I know I can use protocol extensions to provide default implementations. Even so, I'll have duplicate code.
Do not take me wrong, I really like protocols and structs and I understand how to use them, but it seems that many of us believe that the is something wrong with classes and the protocol/struct is the new Holy Grail. I disagree. New possibilites and new way to do things are always welcome, mainly if they are solid and consistent and really solves the problem intended to be solved.
I also understand that the Swift team does not want to introduce any new keywords to the language. To tell the truth I think I need to read again all the information on Swift. I thought the Swift would be one thing, but looks like it will be another. It is likely that the wrong one is me.
Provide ways to create abstract classes and abstract methods is not a "keystroke saver". It is one of many concepts involved in OOP, IMHO.
-Van
On Fri, Feb 26, 2016 at 3:45 PM, Vinicius Vendramini <vinivendra@gmail.com <mailto:vinivendra@gmail.com>> wrote:
It seems like having a protocol restricted to instances of âAccountAuthorizationControllerâ (as Brent suggested) would solve your problem, wouldnât it?
You could just add all method declarations that are supposed to be abstract to that protocol instead, and then make sure your subclasses implement the protocol - which means the compiler forces them to implement the abstract methods.
> Currently I have in a private framework a class named `AccountAuthorizationController` with subclasses like `OAuthAccountAuthorizationController`, `OAuth2AccountAuthorizationController` and `WebFormAccountAuthorizationController` and so on.
>
> In the root "abstract" class I have methods without implementation where I have to use `fatalError()` to ensure that they will never been called. I cannot prevent the framework user to instantiate the `AccountAuthorizationController`, however.
>
> Look that this is only one example. I have other cases as well when I'd like to have abstract classes and abstract methods.
>
> I know that structs and protocols are "elegant, simple and powerful" (as they seem to be all new frameworks and languages that pop up every day on the Internet) and the argumentsin favor of composition rather than inheritance. But I still would like to take advantage of the decades of available knowledge in object orientation in my projects.
>
> +1 for abstract classes and abstract methods.
>
> -Van
>
> On Fri, Feb 26, 2016 at 12:46 PM, Evan Maloney via swift-evolution<swift-evolution@swift.org <mailto:swift-evolution@swift.org>(mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>)>wrote:
> > >Well not exactly, if you want the same behaviors in subclasses of UIViewController and UITableViewController :
> > >- with protocols + extensions, you write in once and apply it to each of your subclasses
> > >- with abstract classes you have to write 2 abstract classes, one for direct UIViewController subclasses, one for UITableViewController subclasses
> >
> > That's a problem with class hierarchies in general, not with abstract classes.
> >
> > You can use the same argument to call for the removal of classes from Swift, which is why I think the fundamental question is, are classes intended to be first-class citizens in Swift?
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org <mailto:swift-evolution@swift.org>(mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>)
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
I would still rather have a solution that extends protocols than one that relies specifically on classes, it seems to me that doing so would make the resulting functionality more generic (for instance, it might be possible to use it with structs as well as classes). However, Iâm starting to agree that this is an important language feature indeed, since I canât think of any better (or even equivalent) way of solving the example you showed.
I'm not sure I understand the desire to make protocols fulfill the role of an abstract class. They're entirely orthogonal concepts.
Protocols are designed to work just as well with structs, enums or classes. Of those, structs and enums have no concept of an inheritance hierarchy. So, the concept of an abstract class is only relevant in one of the three places where a protocol might be used.
It seems to me it would make sense to limit the 'abstract' concept to just classes, and not have the concept leak through to other things where is may not be relevant (i.e. protocols) and where it definitely wouldn't be relevant (structs and enums).
2016/02/29 11:27ăEvan Maloney via swift-evolution <swift-evolution@swift.org> ăźăĄăă»ăŒăž:
···
I would still rather have a solution that extends protocols than one that relies specifically on classes, it seems to me that doing so would make the resulting functionality more generic (for instance, it might be possible to use it with structs as well as classes). However, Iâm starting to agree that this is an important language feature indeed, since I canât think of any better (or even equivalent) way of solving the example you showed.
I'm not sure I understand the desire to make protocols fulfill the role of an abstract class. They're entirely orthogonal concepts.
Protocols are designed to work just as well with structs, enums or classes. Of those, structs and enums have no concept of an inheritance hierarchy. So, the concept of an abstract class is only relevant in one of the three places where a protocol might be used.
It seems to me it would make sense to limit the 'abstract' concept to just classes, and not have the concept leak through to other things where is may not be relevant (i.e. protocols) and where it definitely wouldn't be relevant (structs and enums).
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
I do understand that. I'm just saying that if we're considering abstract class functionality, it would make sense to host that functionality within classes and not have it housed within protocols which work with non-inheritable types like structs and enums.
The latter would need to needless conceptual leakage.
···
2016/02/29 11:27ăEvan Maloney via swift-evolution <swift-evolution@swift.org> ăźăĄăă»ăŒăž:
I would still rather have a solution that extends protocols than one that relies specifically on classes, it seems to me that doing so would make the resulting functionality more generic (for instance, it might be possible to use it with structs as well as classes). However, Iâm starting to agree that this is an important language feature indeed, since I canât think of any better (or even equivalent) way of solving the example you showed.
I'm not sure I understand the desire to make protocols fulfill the role of an abstract class. They're entirely orthogonal concepts.
Protocols are designed to work just as well with structs, enums or classes. Of those, structs and enums have no concept of an inheritance hierarchy. So, the concept of an abstract class is only relevant in one of the three places where a protocol might be used.
It seems to me it would make sense to limit the 'abstract' concept to just classes, and not have the concept leak through to other things where is may not be relevant (i.e. protocols) and where it definitely wouldn't be relevant (structs and enums).
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
I do understand that. I'm just saying that if we're considering abstract class functionality, it would make sense to host that functionality within classes and not have it housed within protocols which work with non-inheritable types like structs and enums.
The latter would need to needless conceptual leakage.
2016/02/29 11:27ăEvan Maloney via swift-evolution <swift-evolution@swift.org> ăźăĄăă»ăŒăž:
I would still rather have a solution that extends protocols than one that relies specifically on classes, it seems to me that doing so would make the resulting functionality more generic (for instance, it might be possible to use it with structs as well as classes). However, Iâm starting to agree that this is an important language feature indeed, since I canât think of any better (or even equivalent) way of solving the example you showed.
I'm not sure I understand the desire to make protocols fulfill the role of an abstract class. They're entirely orthogonal concepts.
Protocols are designed to work just as well with structs, enums or classes. Of those, structs and enums have no concept of an inheritance hierarchy. So, the concept of an abstract class is only relevant in one of the three places where a protocol might be used.
It seems to me it would make sense to limit the 'abstract' concept to just classes, and not have the concept leak through to other things where is may not be relevant (i.e. protocols) and where it definitely wouldn't be relevant (structs and enums).
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
I think that the current approach of wishing protocols could basically do everything might be adding too much responsibility and complexity to the POP pattern, but I think both inheritance and protocol oriented programming should receive equal care at this point. Better access control for properties and methods as well as abstract classes are a way to improve inheritance/OOP that is sorely needed and we should discuss improvements to protocol in their own context... without snide remarks on how improvements there actually negate a feature somewhere else.
I think we need to move forward from the OOP vs POP debate, I do think Swift can support and evolve both approaches...
···
Sent from my iPhone
On 29 Feb 2016, at 16:47, Evan Maloney via swift-evolution <swift-evolution@swift.org> wrote:
You can write class-only protocols in Swift.
I do understand that. I'm just saying that if we're considering abstract class functionality, it would make sense to host that functionality within classes and not have it housed within protocols which work with non-inheritable types like structs and enums.
The latter would need to needless conceptual leakage.
2016/02/29 11:27ăEvan Maloney via swift-evolution <swift-evolution@swift.org> ăźăĄăă»ăŒăž:
I would still rather have a solution that extends protocols than one that relies specifically on classes, it seems to me that doing so would make the resulting functionality more generic (for instance, it might be possible to use it with structs as well as classes). However, Iâm starting to agree that this is an important language feature indeed, since I canât think of any better (or even equivalent) way of solving the example you showed.
I'm not sure I understand the desire to make protocols fulfill the role of an abstract class. They're entirely orthogonal concepts.
Protocols are designed to work just as well with structs, enums or classes. Of those, structs and enums have no concept of an inheritance hierarchy. So, the concept of an abstract class is only relevant in one of the three places where a protocol might be used.
It seems to me it would make sense to limit the 'abstract' concept to just classes, and not have the concept leak through to other things where is may not be relevant (i.e. protocols) and where it definitely wouldn't be relevant (structs and enums).
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
You do have a point here. For some reason I was thinking that structs also supported inheritance - in which case it made more sense to me to add the feature to protocols, so that structs could use it too.
In that case, Iâm sold on implementing this in classes instead of protocols. +1 from me :)
As a side note, being able to constrain protocols to subclasses might be something interesting to pursue later.
···
On Feb 29, 2016, at 1:00 PM, Goffredo Marocchi <panajev@gmail.com> wrote:
I think that the current approach of wishing protocols could basically do everything might be adding too much responsibility and complexity to the POP pattern, but I think both inheritance and protocol oriented programming should receive equal care at this point. Better access control for properties and methods as well as abstract classes are a way to improve inheritance/OOP that is sorely needed and we should discuss improvements to protocol in their own context... without snide remarks on how improvements there actually negate a feature somewhere else.
I think we need to move forward from the OOP vs POP debate, I do think Swift can support and evolve both approaches...
Sent from my iPhone
On 29 Feb 2016, at 16:47, Evan Maloney via swift-evolution <swift-evolution@swift.org> wrote:
You can write class-only protocols in Swift.
I do understand that. I'm just saying that if we're considering abstract class functionality, it would make sense to host that functionality within classes and not have it housed within protocols which work with non-inheritable types like structs and enums.
The latter would need to needless conceptual leakage.
2016/02/29 11:27ăEvan Maloney via swift-evolution <swift-evolution@swift.org> ăźăĄăă»ăŒăž:
I would still rather have a solution that extends protocols than one that relies specifically on classes, it seems to me that doing so would make the resulting functionality more generic (for instance, it might be possible to use it with structs as well as classes). However, Iâm starting to agree that this is an important language feature indeed, since I canât think of any better (or even equivalent) way of solving the example you showed.
I'm not sure I understand the desire to make protocols fulfill the role of an abstract class. They're entirely orthogonal concepts.
Protocols are designed to work just as well with structs, enums or classes. Of those, structs and enums have no concept of an inheritance hierarchy. So, the concept of an abstract class is only relevant in one of the three places where a protocol might be used.
It seems to me it would make sense to limit the 'abstract' concept to just classes, and not have the concept leak through to other things where is may not be relevant (i.e. protocols) and where it definitely wouldn't be relevant (structs and enums).
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
On Mon, Feb 29, 2016 at 3:00 PM, Goffredo Marocchi via swift-evolution < swift-evolution@swift.org> wrote:
I think that the current approach of wishing protocols could basically do
everything might be adding too much responsibility and complexity to the
POP pattern, but I think both inheritance and protocol oriented programming
should receive equal care at this point. Better access control for
properties and methods as well as abstract classes are a way to improve
inheritance/OOP that is sorely needed and we should discuss improvements to
protocol in their own context... without snide remarks on how improvements
there actually negate a feature somewhere else.
I think we need to move forward from the OOP vs POP debate, I do think
Swift can support and evolve both approaches...
Sent from my iPhone
On 29 Feb 2016, at 16:47, Evan Maloney via swift-evolution < > swift-evolution@swift.org> wrote:
>> You can write class-only protocols in Swift.
>
> I do understand that. I'm just saying that if we're considering abstract
class functionality, it would make sense to host that functionality within
classes and not have it housed within protocols which work with
non-inheritable types like structs and enums.
>
> The latter would need to needless conceptual leakage.
>
>
>> 2016/02/29 11:27ăEvan Maloney via swift-evolution <
swift-evolution@swift.org> ăźăĄăă»ăŒăž:
>>
>>>> I would still rather have a solution that extends protocols than one
that relies specifically on classes, it seems to me that doing so would
make the resulting functionality more generic (for instance, it might be
possible to use it with structs as well as classes). However, Iâm starting
to agree that this is an important language feature indeed, since I canât
think of any better (or even equivalent) way of solving the example you
showed.
>>>
>>> I'm not sure I understand the desire to make protocols fulfill the
role of an abstract class. They're entirely orthogonal concepts.
>>>
>>> Protocols are designed to work just as well with structs, enums or
classes. Of those, structs and enums have no concept of an inheritance
hierarchy. So, the concept of an abstract class is only relevant in one of
the three places where a protocol might be used.
>>>
>>> It seems to me it would make sense to limit the 'abstract' concept to
just classes, and not have the concept leak through to other things where
is may not be relevant (i.e. protocols) and where it definitely wouldn't be
relevant (structs and enums).
>>> _______________________________________________
>>> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Yet mutating methods declared in a protocol can be implemented by classes, and are not reserved to structs.
I think that Evanâs reasoning is the following:
1. Swift has classes, and supports class inheritance. Itâs a plain fact.
2. The concept of "abstract class" is tied to classes, and only classes, since it requires inheritance in its very definition.
3. Hence the concept of "abstract class" belongs to the class realm, and protocols have nothing do to with it.
I do understand that. I'm just saying that if we're considering abstract class functionality, it would make sense to host that functionality within classes and not have it housed within protocols which work with non-inheritable types like structs and enums.
The latter would need to needless conceptual leakage.
2016/02/29 11:27ăEvan Maloney via swift-evolution <swift-evolution@swift.org> ăźăĄăă»ăŒăž:
I would still rather have a solution that extends protocols than one that relies specifically on classes, it seems to me that doing so would make the resulting functionality more generic (for instance, it might be possible to use it with structs as well as classes). However, Iâm starting to agree that this is an important language feature indeed, since I canât think of any better (or even equivalent) way of solving the example you showed.
I'm not sure I understand the desire to make protocols fulfill the role of an abstract class. They're entirely orthogonal concepts.
Protocols are designed to work just as well with structs, enums or classes. Of those, structs and enums have no concept of an inheritance hierarchy. So, the concept of an abstract class is only relevant in one of the three places where a protocol might be used.
It seems to me it would make sense to limit the 'abstract' concept to just classes, and not have the concept leak through to other things where is may not be relevant (i.e. protocols) and where it definitely wouldn't be relevant (structs and enums).
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Yet mutating methods declared in a protocol can be implemented by classes, and are not reserved to structs.
I think that Evanâs reasoning is the following:
1. Swift has classes, and supports class inheritance. Itâs a plain fact.
2. The concept of "abstract class" is tied to classes, and only classes, since it requires inheritance in its very definition.
3. Hence the concept of "abstract class" belongs to the class realm, and protocols have nothing do to with it.
Yet mutating methods declared in a protocol can be implemented by classes, and are not reserved to structs.
I think that Evanâs reasoning is the following:
1. Swift has classes, and supports class inheritance. Itâs a plain fact.
2. The concept of "abstract class" is tied to classes, and only classes, since it requires inheritance in its very definition.
3. Hence the concept of "abstract class" belongs to the class realm, and protocols have nothing do to with it.
I do understand that. I'm just saying that if we're considering abstract class functionality, it would make sense to host that functionality within classes and not have it housed within protocols which work with non-inheritable types like structs and enums.
The latter would need to needless conceptual leakage.
2016/02/29 11:27ăEvan Maloney via swift-evolution <swift-evolution@swift.org> ăźăĄăă»ăŒăž:
I would still rather have a solution that extends protocols than one that relies specifically on classes, it seems to me that doing so would make the resulting functionality more generic (for instance, it might be possible to use it with structs as well as classes). However, Iâm starting to agree that this is an important language feature indeed, since I canât think of any better (or even equivalent) way of solving the example you showed.
I'm not sure I understand the desire to make protocols fulfill the role of an abstract class. They're entirely orthogonal concepts.
Protocols are designed to work just as well with structs, enums or classes. Of those, structs and enums have no concept of an inheritance hierarchy. So, the concept of an abstract class is only relevant in one of the three places where a protocol might be used.
It seems to me it would make sense to limit the 'abstract' concept to just classes, and not have the concept leak through to other things where is may not be relevant (i.e. protocols) and where it definitely wouldn't be relevant (structs and enums).
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution