abstract keyWord proposal

Hi Everyone,

  Nice to see this new swift-evolution process….I’m not sure to completely understand the whole process of requesting evolutions, but I’m trying
to do…

  As I develop sort of framework, I usually have classes that I wanted to partially in the framework and force the user to implement others parts.

  For example, I have a WebService class that manage the whole process to perform asynchronous call, error management.
  This class has an abstract property that is specific for each WebService call.

  Then I would like to make the URL property abstract and, consequently, the whole WebService class abstract : The WebService cannot be directly instantiated.

  The goal of this feature would be to extend to method.
  This behavior already exists in Java and is really useful.

  The workaround is to make an URL property that returns invalid value or make assertion, but the error is only detected at runtime.

  My proposal would be to just add a keyword before func, class or var. An abstract property or func should not provide implementation.

  Regards,

David

Hello David,

This sounds like something that can be accomplished with protocols and
default implementations provided in protocol extensions. If you've
watched Protocol-Oriented
Programming in Swift [Session 408]
<Design and Development Videos - Apple Developer, slides 168 and on,
once he begins talking about Protocol Extensions, is the relevant part. It
looks like the functionality that you've described is already present in
this feature.

TJ

···

On Fri, Dec 4, 2015 at 3:30 AM, David Scrève <david.screve@dlta-studio.com> wrote:

        Hi Everyone,

        Nice to see this new swift-evolution process….I’m not sure to
completely understand the whole process of requesting evolutions, but I’m
trying
to do…

        As I develop sort of framework, I usually have classes that I
wanted to partially in the framework and force the user to implement others
parts.

        For example, I have a WebService class that manage the whole
process to perform asynchronous call, error management.
        This class has an abstract property that is specific for each
WebService call.

        Then I would like to make the URL property abstract and,
consequently, the whole WebService class abstract : The WebService cannot
be directly instantiated.

        The goal of this feature would be to extend to method.
        This behavior already exists in Java and is really useful.

        The workaround is to make an URL property that returns invalid
value or make assertion, but the error is only detected at runtime.

        My proposal would be to just add a keyword before func, class or
var. An abstract property or func should not provide implementation.

        Regards,

David

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

Hello TJ,

  Actually not completely…Protocol does not handle properties storage. Only class (and struct) can be made abstract.

  Doing this with protocol and class required the use of both and you need to enforce developer to inherit from class and implement protocol.. An abstract class encapsulate both on this in a single entity.

  Here is a sample class for WebService :

class WebService {
    private var lastModified : NSDate
    var url : String?

    init() {
        lastModified=NSDate()
    }
    
    func performCall() {
        print(self.url)
        self.lastModified=NSDate()
    }
}

As written below, I can create a WebService instance…but I would like to forbid this because URL is a property that must be implemented by inherited classes.

I I use a protocol and Protocol extension, I will not be able to have lastModified stored value.

My proposal is to add abstract keyword as below :

abstract class WebService {
    private var lastModified : NSDate
    abstract var url : String?

    init() {
        lastModified=NSDate()
    }
    
    func performCall() {
        print(self.url)
        self.lastModified=NSDate()
    }
}

Then I will not be able to create a WebService object, and enforced to implement url property in inherited classes.

  Regards,

David

···

Le 4 déc. 2015 à 09:43, T.J. Usiyan <griotspeak@gmail.com> a écrit :

Hello David,

This sounds like something that can be accomplished with protocols and default implementations provided in protocol extensions. If you've watched Protocol-Oriented Programming in Swift [Session 408] <Design and Development Videos - Apple Developer, slides 168 and on, once he begins talking about Protocol Extensions, is the relevant part. It looks like the functionality that you've described is already present in this feature.

TJ

On Fri, Dec 4, 2015 at 3:30 AM, David Scrève <david.screve@dlta-studio.com <mailto:david.screve@dlta-studio.com>> wrote:
        Hi Everyone,

        Nice to see this new swift-evolution process….I’m not sure to completely understand the whole process of requesting evolutions, but I’m trying
to do…

        As I develop sort of framework, I usually have classes that I wanted to partially in the framework and force the user to implement others parts.

        For example, I have a WebService class that manage the whole process to perform asynchronous call, error management.
        This class has an abstract property that is specific for each WebService call.

        Then I would like to make the URL property abstract and, consequently, the whole WebService class abstract : The WebService cannot be directly instantiated.

        The goal of this feature would be to extend to method.
        This behavior already exists in Java and is really useful.

        The workaround is to make an URL property that returns invalid value or make assertion, but the error is only detected at runtime.

        My proposal would be to just add a keyword before func, class or var. An abstract property or func should not provide implementation.

        Regards,

David

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

Hello,

This is an interesting example. I can't refute it without questioning
decisions/intent rather than code so I'll just say that the `abstract`
quality you're after still seems like it should be fit into the protocol
family of features.

TJ

···

On Fri, Dec 4, 2015 at 3:56 AM, David Scrève <david.screve@dlta-studio.com> wrote:

Hello TJ,

Actually not completely…Protocol does not handle properties storage. Only
class (and struct) can be made abstract.

Doing this with protocol and class required the use of both and you need
to enforce developer to inherit from class and implement protocol.. An
abstract class encapsulate both on this in a single entity.

Here is a sample class for WebService :

class WebService {
    private var lastModified : NSDate
    var url : String?

    init() {
        lastModified=NSDate()
    }

    func performCall() {
        print(self.url)
        self.lastModified=NSDate()
    }
}

As written below, I can create a WebService instance…but I would like to
forbid this because URL is a property that must be implemented by inherited
classes.

I I use a protocol and Protocol extension, I will not be able to have
lastModified stored value.

My proposal is to add abstract keyword as below :

abstract class WebService {
    private var lastModified : NSDate
    abstract var url : String?

    init() {
        lastModified=NSDate()
    }

    func performCall() {
        print(self.url)
        self.lastModified=NSDate()
    }
}

Then I will not be able to create a WebService object, and enforced to
implement url property in inherited classes.

Regards,

David

Le 4 déc. 2015 à 09:43, T.J. Usiyan <griotspeak@gmail.com> a écrit :

Hello David,

This sounds like something that can be accomplished with protocols and
default implementations provided in protocol extensions. If you've watched Protocol-Oriented
Programming in Swift [Session 408]
<Design and Development Videos - Apple Developer, slides 168 and
on, once he begins talking about Protocol Extensions, is the relevant part.
It looks like the functionality that you've described is already present in
this feature.

TJ

On Fri, Dec 4, 2015 at 3:30 AM, David Scrève <david.screve@dlta-studio.com > > wrote:

        Hi Everyone,

        Nice to see this new swift-evolution process….I’m not sure to
completely understand the whole process of requesting evolutions, but I’m
trying
to do…

        As I develop sort of framework, I usually have classes that I
wanted to partially in the framework and force the user to implement others
parts.

        For example, I have a WebService class that manage the whole
process to perform asynchronous call, error management.
        This class has an abstract property that is specific for each
WebService call.

        Then I would like to make the URL property abstract and,
consequently, the whole WebService class abstract : The WebService cannot
be directly instantiated.

        The goal of this feature would be to extend to method.
        This behavior already exists in Java and is really useful.

        The workaround is to make an URL property that returns invalid
value or make assertion, but the error is only detected at runtime.

        My proposal would be to just add a keyword before func, class or
var. An abstract property or func should not provide implementation.

        Regards,

David

_______________________________________________
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

Yes,

  I agree with you that abstract might be attached to protocol family of feature…but protocol already manage the ‘abstract’ feature if you don’t consider the value storage issue.

  Actually, there 2 ways to add this feature :

  1 - Protocol way : We need to add value storage to protocol
  2 - class way : We need to add abstract for method/properties

  The question is : Is adding value storage to protocol is a good thing ? It might create confusion between classes and protocol, maybe.

  But, on the other side, there is not real reason to limit class extension to only method and not to properties. In this case, extending protocol to value container might be an interesting way to respond to this. Anyway, we might keep the abstract keyword.

  Regards,

David

···

Le 4 déc. 2015 à 10:11, T.J. Usiyan <griotspeak@gmail.com> a écrit :

Hello,

This is an interesting example. I can't refute it without questioning decisions/intent rather than code so I'll just say that the `abstract` quality you're after still seems like it should be fit into the protocol family of features.

TJ

On Fri, Dec 4, 2015 at 3:56 AM, David Scrève <david.screve@dlta-studio.com <mailto:david.screve@dlta-studio.com>> wrote:
  Hello TJ,

  Actually not completely…Protocol does not handle properties storage. Only class (and struct) can be made abstract.

  Doing this with protocol and class required the use of both and you need to enforce developer to inherit from class and implement protocol.. An abstract class encapsulate both on this in a single entity.

  Here is a sample class for WebService :

class WebService {
    private var lastModified : NSDate
    var url : String?

    init() {
        lastModified=NSDate()
    }
    
    func performCall() {
        print(self.url)
        self.lastModified=NSDate()
    }
}

As written below, I can create a WebService instance…but I would like to forbid this because URL is a property that must be implemented by inherited classes.

I I use a protocol and Protocol extension, I will not be able to have lastModified stored value.

My proposal is to add abstract keyword as below :

abstract class WebService {
    private var lastModified : NSDate
    abstract var url : String?

    init() {
        lastModified=NSDate()
    }
    
    func performCall() {
        print(self.url)
        self.lastModified=NSDate()
    }
}

Then I will not be able to create a WebService object, and enforced to implement url property in inherited classes.

  Regards,

David

Le 4 déc. 2015 à 09:43, T.J. Usiyan <griotspeak@gmail.com <mailto:griotspeak@gmail.com>> a écrit :

Hello David,

This sounds like something that can be accomplished with protocols and default implementations provided in protocol extensions. If you've watched Protocol-Oriented Programming in Swift [Session 408] <Design and Development Videos - Apple Developer, slides 168 and on, once he begins talking about Protocol Extensions, is the relevant part. It looks like the functionality that you've described is already present in this feature.

TJ

On Fri, Dec 4, 2015 at 3:30 AM, David Scrève <david.screve@dlta-studio.com <mailto:david.screve@dlta-studio.com>> wrote:
        Hi Everyone,

        Nice to see this new swift-evolution process….I’m not sure to completely understand the whole process of requesting evolutions, but I’m trying
to do…

        As I develop sort of framework, I usually have classes that I wanted to partially in the framework and force the user to implement others parts.

        For example, I have a WebService class that manage the whole process to perform asynchronous call, error management.
        This class has an abstract property that is specific for each WebService call.

        Then I would like to make the URL property abstract and, consequently, the whole WebService class abstract : The WebService cannot be directly instantiated.

        The goal of this feature would be to extend to method.
        This behavior already exists in Java and is really useful.

        The workaround is to make an URL property that returns invalid value or make assertion, but the error is only detected at runtime.

        My proposal would be to just add a keyword before func, class or var. An abstract property or func should not provide implementation.

        Regards,

David

_______________________________________________
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

I don't think there'd be much confusion with allowing protocol extensions
to contain stored types but I could easily see that being very difficult to
implement.

···

On Fri, Dec 4, 2015 at 4:24 AM David Scrève <david.screve@dlta-studio.com> wrote:

Yes,

I agree with you that abstract might be attached to protocol family of
feature…but protocol already manage the ‘abstract’ feature if you don’t
consider the value storage issue.

Actually, there 2 ways to add this feature :

1 - Protocol way : We need to add value storage to protocol
2 - class way : We need to add abstract for method/properties

The question is : Is adding value storage to protocol is a good thing ?
It might create confusion between classes and protocol, maybe.

But, on the other side, there is not real reason to limit class extension
to only method and not to properties. In this case, extending protocol to
value container might be an interesting way to respond to this. Anyway, we
might keep the abstract keyword.

Regards,

David

Le 4 déc. 2015 à 10:11, T.J. Usiyan <griotspeak@gmail.com> a écrit :

Hello,

This is an interesting example. I can't refute it without questioning
decisions/intent rather than code so I'll just say that the `abstract`
quality you're after still seems like it should be fit into the protocol
family of features.

TJ

On Fri, Dec 4, 2015 at 3:56 AM, David Scrève <david.screve@dlta-studio.com > > wrote:

Hello TJ,

Actually not completely…Protocol does not handle properties storage. Only
class (and struct) can be made abstract.

Doing this with protocol and class required the use of both and you need
to enforce developer to inherit from class and implement protocol.. An
abstract class encapsulate both on this in a single entity.

Here is a sample class for WebService :

class WebService {
    private var lastModified : NSDate
    var url : String?

    init() {
        lastModified=NSDate()
    }

    func performCall() {
        print(self.url)
        self.lastModified=NSDate()
    }
}

As written below, I can create a WebService instance…but I would like to
forbid this because URL is a property that must be implemented by inherited
classes.

I I use a protocol and Protocol extension, I will not be able to have
lastModified stored value.

My proposal is to add abstract keyword as below :

abstract class WebService {
    private var lastModified : NSDate
    abstract var url : String?

    init() {
        lastModified=NSDate()
    }

    func performCall() {
        print(self.url)
        self.lastModified=NSDate()
    }
}

Then I will not be able to create a WebService object, and enforced to
implement url property in inherited classes.

Regards,

David

Le 4 déc. 2015 à 09:43, T.J. Usiyan <griotspeak@gmail.com> a écrit :

Hello David,

This sounds like something that can be accomplished with protocols and
default implementations provided in protocol extensions. If you've watched Protocol-Oriented
Programming in Swift [Session 408]
<Design and Development Videos - Apple Developer, slides 168 and
on, once he begins talking about Protocol Extensions, is the relevant part.
It looks like the functionality that you've described is already present in
this feature.

TJ

On Fri, Dec 4, 2015 at 3:30 AM, David Scrève < >> david.screve@dlta-studio.com> wrote:

        Hi Everyone,

        Nice to see this new swift-evolution process….I’m not sure to
completely understand the whole process of requesting evolutions, but I’m
trying
to do…

        As I develop sort of framework, I usually have classes that I
wanted to partially in the framework and force the user to implement others
parts.

        For example, I have a WebService class that manage the whole
process to perform asynchronous call, error management.
        This class has an abstract property that is specific for each
WebService call.

        Then I would like to make the URL property abstract and,
consequently, the whole WebService class abstract : The WebService cannot
be directly instantiated.

        The goal of this feature would be to extend to method.
        This behavior already exists in Java and is really useful.

        The workaround is to make an URL property that returns invalid
value or make assertion, but the error is only detected at runtime.

        My proposal would be to just add a keyword before func, class or
var. An abstract property or func should not provide implementation.

        Regards,

David

_______________________________________________
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

I agree, I believe allowing stored types either in protocols or in classes might be very difficult to implement. I don’t even think this is allowed in Objective-C, probably for the same reason.

···

On Dec 4, 2015, at 8:36 AM, Tal Atlas <me@tal.by> wrote:

I don't think there'd be much confusion with allowing protocol extensions to contain stored types but I could easily see that being very difficult to implement.