[swift-evolution] [Proposal draff] abstract classes and methods
Goffredo Marocchi
panajev at gmail.com
Thu Jan 7 13:50:25 CST 2016
True too, but I think there is some overreaction too especially with the heavy push from FP programmers. Truth is that composition, inheritance, and functional programming are all tools and not religions. We can learn from each how to code better in general and mix and match.
Although this talk predates Swift's default methods/mixins, and so it stops earlier than you might like, it makes a lot of valid points:
Watch “Somewhere Between Tomorrowland and Frontierland - Daniel Steinberg” on Vimeo: https://vimeo.com/124349158
Sent from my iPhone
> On 7 Jan 2016, at 19:41, Charles Constant <charles at charlesism.com> wrote:
>
> > I am not sure that the language should discourage a feature it supports and impose friction on it because it could be abused.
>
> Especially since the OOP philosophy is falling out of fashion anyway. Thousands of CompSci profs, and programming blogs, all saying "we've come to our senses, OOP is confusing". Adding Abstract classes to Swift isn't going to turn that ship around.
>
>
>
>> On Thu, Jan 7, 2016 at 11:27 AM, Goffredo Marocchi <panajev at gmail.com> wrote:
>> Hello David,
>>
>> I am not sure that the language should discourage a feature it supports and impose friction on it because it could be abused. Composition does not mean you should never subclass and Swift should not make it trickier to implement inheritance although I could agree it should not bend over backwards for it either.
>> I think this proposal goes along this direction.
>>
>> With that said, this is where protocols and protocol extensions with default methods come in, but there we have the static dispatching of the methods declare in the protocol extension with the default implementation unless they were also created in the original protocol in which case the default implementation is only used if the type implementing the protocol does not override it... That area needs some revisiting too perhaps.
>>
>> Sent from my iPhone
>>
>>> On 7 Jan 2016, at 18:42, David James via swift-evolution <swift-evolution at swift.org> wrote:
>>>
>>> Not sure the language direction should encourage inheritance based structures, which abstract classes and methods do. That’s not to say that inheritance is dead, but that a modern language should encourage and support compositional patterns rather than inheritance based patterns.
>>>
>>>> On Jan 7, 2016, at 7:19 PM, charles--- via swift-evolution <swift-evolution at swift.org> wrote:
>>>>
>>>> +1
>>>>
>>>> I have loads of "pretend abstract" classes littered with stuff like this:
>>>>
>>>> var boo:Bool! { return nil /*DUMMY*/ }
>>>>
>>>> It takes a significant amount of energy atm to plan a Swift project because there are quirky differences between: protocol / subclass / class extension. It's not so straightforward to pick the most appropriate one.
>>>>
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On Jan 7, 2016, at 9:55 AM, David Scrève via swift-evolution <swift-evolution at swift.org> wrote:
>>>>>
>>>>> # Abstract classes and methods
>>>>>
>>>>> * Author(s): David Scrève
>>>>>
>>>>> ## Introduction
>>>>>
>>>>> When developing framework and reusable, we need to develop classes that are partially
>>>>> abstract with partial implementation. Protocol and protocol extensions provide this, but
>>>>> they cannot have attributes as classes have.
>>>>> A partial class combines the behavior of a class with the requirement of implementing methods
>>>>> in inherited class like protocols.
>>>>>
>>>>> Swift-evolution thread: [link to the discussion thread for that proposal](https://lists.swift.org/pipermail/swift-evolution)
>>>>>
>>>>> ## Motivation
>>>>> Like pure virtual methods in C++ and abtract classes in Java and C#, frameworks development
>>>>> sometimes required abstract classes facility.
>>>>> An abstract class is like a regular class, but some methods/properties are not implemented
>>>>> and must be implemented in one of inherited classes.
>>>>> An abstract class can inherit from other class, implements protocols and has members
>>>>> attributes as opposite from protocols.
>>>>> Only some methods and properties might be abstract.
>>>>> The goal of abstract classes is to encapsulate a generic behavior that may need some
>>>>> specific implementation methods which are not known in abstract class. This behavior
>>>>> requires attributes that are used by internal abstract class method.
>>>>>
>>>>> Example :
>>>>> Considere a generic RESTClient that is included in a framework :
>>>>>
>>>>> ```swift
>>>>> class RESTClient {
>>>>>
>>>>> var timeout = 3000
>>>>>
>>>>> var url : String {
>>>>> assert(false,"Must be overriden")
>>>>> return ""
>>>>> }
>>>>>
>>>>> func performNetworkCall() {
>>>>> let restURL = self.url
>>>>> print("Performing URL call to \(restURL) with timeout \(self.timeout)")
>>>>> }
>>>>> }
>>>>>
>>>>> ```
>>>>>
>>>>> And an implementation :
>>>>> ```swift
>>>>> class MyRestServiceClient : RESTClient {
>>>>> override var url : String {
>>>>> return "http://www.foo.com/client"
>>>>> }
>>>>>
>>>>> }
>>>>> ```
>>>>>
>>>>> As you can see, url properties must be implemented by inherited class and should not be
>>>>> implemented by ancestor.
>>>>> As workaround, we have added assertion, but this error is only detected at runtime and not
>>>>> at compile time and might create crash for end-user.
>>>>>
>>>>> ## Proposed solution
>>>>> We propose to add a new keyword to indicate that a method or a property is abstract and
>>>>> not implemented in current class.
>>>>> This indicates that method or properties must be implemented in inherited class that can
>>>>> be implemented.
>>>>> We propose the keyword abstract that must be added to class and property/method :
>>>>>
>>>>> ```swift
>>>>> abstract class RESTClient {
>>>>> var timeout = 3000
>>>>>
>>>>> abstract var url : String { get }
>>>>>
>>>>> func performNetworkCall() {
>>>>> let restURL = self.url
>>>>> print("Performing URL call to \(restURL) with timeout \(self.timeout)")
>>>>> }
>>>>> }
>>>>> ```
>>>>>
>>>>> And an implementation :
>>>>> ```swift
>>>>> class MyRestServiceClient : RESTClient {
>>>>> override var url : String {
>>>>> return "http://www.foo.com/client"
>>>>> }
>>>>>
>>>>> }
>>>>> ```
>>>>>
>>>>> ## Detailed design
>>>>> An abstract class cannot be instanciated.
>>>>>
>>>>> If a class contains one or more abstract methods/properties, it must be declared abstract.
>>>>>
>>>>> A class that inherits from abstract must be declared abstract if it does not implements
>>>>> all inherited methods/properties.
>>>>>
>>>>> If you try to implement an abstract class or a inherited class that implements partially
>>>>> abstract methods/properties, you will get a compiler error.
>>>>>
>>>>> As for override keyword, abstract properties apply on setter, getter and observers.
>>>>>
>>>>> When declaring an abstract property, you must specify which methods must be implemented :
>>>>> get, set, didSet, willSet.
>>>>>
>>>>> If you do not specify anything, only setter and getter are made
>>>>> abstracts as below :
>>>>>
>>>>> ```swift
>>>>> abstract var url : String
>>>>> ```
>>>>>
>>>>> Observers provides default empty implementation.
>>>>>
>>>>> Type is mandatory for abstract properties since it cannot be inferred.
>>>>>
>>>>> ## Impact on existing code
>>>>> This change has no impact on existing code, but might change the ABI that is being
>>>>> stabilizing in Swift 3.0.
>>>>>
>>>>> ## Alternatives considered
>>>>> As first reading, it seems that protocols and protocol extensions might fit the need. It
>>>>> actually does not because abstract classes can have attributs and properties that
>>>>> protocols does not support.
>>>>>
>>>>> An alternative solution would be to add attributes to protocols and protocol extensions,
>>>>> but this might break compatibility with Objective-C runtime.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> David James
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160107/5e778eab/attachment.html>
More information about the swift-evolution
mailing list