[swift-evolution] abstract keyWord proposal

[T.J. Usiyan]

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 at 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 at 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]
> <https://developer.apple.com/videos/play/wwdc2015-408/>, 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 at 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 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151204/bef3b9e7/attachment.html>