[swift-evolution] abstract keyWord proposal

[Tal Atlas]

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 at 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 at 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 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
>>
>>
>
> _______________________________________________
> 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/53714029/attachment-0001.html>