[swift-evolution] [Review] SE-0026 Abstract classes and methods

[Vanderlei Martinelli]

>From the other thread, quoting myself:

"Do not take me wrong, I really like protocols and structs and I understand
how to use them, but it seems that many of us believe that the is something
wrong with classes and the protocol/struct is the new Holy Grail. I
disagree. New possibilites and new way to do things are always welcome,
mainly if they are solid and consistent and really solves the
problem intended to be solved.

I also understand that the Swift team does not want to introduce any new
keywords to the language. To tell the truth I think I need to read again
all the information on Swift. I thought the Swift would be one thing, but
looks like it will be another. It is likely that the wrong one is me.

Provide ways to create abstract classes and abstract methods is not a
"keystroke saver". It is one of many concepts involved in OOP, IMHO."

-Van

On Fri, Feb 26, 2016 at 4:21 PM, Sean Heber via swift-evolution <
swift-evolution at swift.org> wrote:

> > Proposal link:
> >
> >
> https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md
> >       • What is your evaluation of the proposal?
>
> I am mixed on this. I’ve mentioned wanting this myself on this list and
> have run into situations where I *really* wished I had it at the time
> (instead of having to do fatalError()), but ultimately I’ve almost always
> gone back to redesign those things to get rid of the abstract base class
> pattern and improved the design in the process. Perhaps this is an
> anti-pattern and Swift should not encourage it. I’m not sure.
>
>
> >       • Is the problem being addressed significant enough to warrant a
> change to Swift?
>
> I’m not so sure. I feel like by not having it, Swift has often pushed me
> toward better design (at the cost of some of my hair).
>
>
> >       • Does this proposal fit well with the feel and direction of Swift?
>
> Again, I’m not sure about this. I don’t think the potential of protocols
> have been fully explored yet and this feels like just adding an old feature
> from old languages because that’s the way we’re used to doing it. I feel
> like you could get the same effect by having a way to apply a single
> protocol to a class “abstractly” and have that *result in* an abstract
> class. This would more clearly separate the parts that are meant for
> subclasses to fill in vs. not. For example, to use the class from the
> proposal:
>
> protocol RESTClientSubclass {
>   var url : String { get }
> }
>
> class RESTClient: @abstract(RESTClientSubclass) {}
>
> class MyRestServiceClient : RESTClient {
>   var url : String { return "http://www.foo.com/client” }
> }
>
> “override” wouldn’t be necessary here because you’re not actually
> overriding anything and the methods/properties the subclass needs to
> implement are clearly grouped together in the RESTClientSubclass protocol.
> (In fact it might even be an error for RESTClient to implement *any* method
> itself in an abstract protocol conformance).
>
>
> >       • If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
> Yes and it doesn’t feel any different - which is what bothers me, perhaps.
> :)
>
>
> >       • How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> Skimmed the discussions as they happened a bit, read the proposal, but did
> not spend significant time on it.
>
> l8r
> Sean
>
> _______________________________________________
> 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/20160226/db125926/attachment.html>