Re: [swift-evolution] Abstract methods

I think there is a legitimate hole around abstract methods. I don’t think it really matters whether you’re talking about a class hierarchy or a protocol hierarchy. They’re both providing partial implementations of behaviour, predicated on some other method being implemented. The practical

Re: [swift-evolution] Abstract methods

On 6 November 2017 at 19:44, Tino Heth <2...@gmx.de> wrote: > to me protocol extensions are both cool and evil. cool as you can add > code. evil because it's more natural to add another declarations in those > extensions rather than implementation: > > protocol Foo { > func foo() > } > >

Re: [swift-evolution] Abstract methods

> to me protocol extensions are both cool and evil. cool as you can add code. > evil because it's more natural to add another declarations in those > extensions rather than implementation: > > protocol Foo { > func foo() > } > > extension Foo { >func bar()//*** natural assumption

Re: [swift-evolution] Abstract methods

> to me protocol extensions are both cool and evil. cool as you can add code. > evil because it's more natural to add another declarations in those > extensions rather than implementation: > > protocol Foo { >func foo() > } > > extension Foo { > func bar()//*** natural assumption is

Re: [swift-evolution] Abstract methods

on Sun, 5 Nov 2017 09:27:09 + Goffredo Marocchi wrote: > > I would say that you kind of already entered a slippery slope when the > extension to a protocol can add code / not just declare a behavioural > contract ... to me protocol extensions are both cool and evil. cool

Re: [swift-evolution] Abstract methods

At least SR-103 is a legitimate bug that we would like to fix one day. Slava > On Nov 5, 2017, at 1:27 AM, Goffredo Marocchi wrote: > > I would say that you kind of already entered a slippery slope when the > extension to a protocol can add code / not just declare a

Re: [swift-evolution] Abstract methods

I would say that you kind of already entered a slippery slope when the extension to a protocol can add code / not just declare a behavioural contract and how it changes OOP approach (hence: https://bugs.swift.org/plugins/servlet/mobile#issue/SR-302 and https://bugs.swift.org/browse/SR-103

Re: [swift-evolution] Abstract methods

> On Nov 4, 2017, at 1:32 AM, Goffredo Marocchi wrote: > > > > Sent from my iPhone > >> On 4 Nov 2017, at 05:26, Slava Pestov via swift-evolution >> wrote: >> >> Protocols define requirements, they don’t “add” things to the conforming type >

Re: [swift-evolution] Abstract methods

> An abstract base class can expose private or internal abstract requirements > to its implementation subclasses while exporting a different interface for > external users. I think what you want for this is real orthogonality of access rights (being able to declare a method that can’t be

Re: [swift-evolution] Abstract methods

I mostly miss this (a.k.a. protected methods): "Protocols don't support language enforcement of separate implementor and user interfaces, since all of a protocol's requirements must be as visible as the conformance. An abstract base class can expose private or internal abstract requirements to

Re: [swift-evolution] Abstract methods

Sent from my iPhone > On 4 Nov 2017, at 05:26, Slava Pestov via swift-evolution > wrote: > > Protocols define requirements, they don’t “add” things to the conforming type I agree with this, but then this warrants a change for protocol extensions too. Would you be

Re: [swift-evolution] Abstract methods

> On Nov 2, 2017, at 8:29 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Nov 2, 2017, at 1:57 PM, Taylor Swift via swift-evolution >> > wrote: >> >> Swift architectures use much less

Re: [swift-evolution] Abstract methods

(Though calling "super" and Implementing non-public methods would round out "protocol as abstract class" functionality.) -- C. Keith Ray * https://leanpub.com/wepntk <- buy my book? * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf * http://agilesolutionspace.blogspot.com/ > On

Re: [swift-evolution] Abstract methods

If protocols can (1) store data (2) implement methods (3) force "subclasses" to implement methods, then I'm ok that it isn't spelled "abstract". And yes, I know 2 and 3 done. -- C. Keith Ray * https://leanpub.com/wepntk <- buy my book? *

Re: [swift-evolution] Abstract methods

> Le 3 nov. 2017 à 04:29, Brent Royal-Gordon via swift-evolution > a écrit : > > I think we should beef up protocols a little bit so that they can serve the > role of abstract classes. That would be great. Back in the day, the proposal SE-0026 "Abstract classes

Re: [swift-evolution] Abstract methods

> On Nov 2, 2017, at 1:57 PM, Taylor Swift via swift-evolution > wrote: > > Swift architectures use much less inheritance (and class types) in general > than equivalent c++ architectures. personally i have never been in a > situation where i didn’t need a pure

Re: [swift-evolution] Abstract methods

How would a class partially implement a protocol? That’s a compile error. > On Nov 2, 2017, at 2:30 PM, C. Keith Ray via swift-evolution > wrote: > > If a class partially implemented a protocol, it also would not be > instantiatable, but a subclass can supply the

Re: [swift-evolution] Abstract methods

If a class partially implemented a protocol, it also would not be instantiatable, but a subclass can supply the missing method(s). Doesn’t the compiler already handle that? How are abstract classes harder? C. Keith Ray https://leanpub.com/wepntk <- buy my book?

Re: [swift-evolution] Abstract methods

Abstract methods and classes seem like they will introduce a fair amount of complexity in the type checker, particularly around metatypes and constructors, because now we have this new concept of a class that cannot be directly instantiated. I’m not sure the cost is worth the benefit. Slava >

Re: [swift-evolution] Abstract methods

Swift does still have inheritance, though. A language with inheritance and not abstract is frustrating to use, as evidenced by the hacks people resort to for Objective-C. If we wanted to steer people away from inheritance then maybe we shouldn’t have supported it at all, but it’s a bit late

Re: [swift-evolution] Abstract methods

Swift architectures use much less inheritance (and class types) in general than equivalent c++ architectures. personally i have never been in a situation where i didn’t need a pure abstract method that was better declared as a protocol requirement. > On Nov 2, 2017, at 2:45 PM, C. Keith Ray

[swift-evolution] Abstract methods

How many "subclass must override" assertions or comments in base class methods do we need to see, to want to add "abstract" to the Swift language? 5? 50? 500? It's a not uncommon idiom in Objective-C. I'm about to port a substantial amount of C++ code to swift, and compiler help to enforce