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

[plx]

> On Feb 26, 2016, at 12:11 PM, Joe Groff 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 <https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md>
> 	• What is your evaluation of the proposal?

A tentative -1; although there are places abstract classes *would* be useful, I can’t think of a single such scenario for which an abstract class would be the *best* solution (or at least the solution I’d prefer).

Since the points I would make here have already been made I won’t belabor this point; suffice to say it’d be a lot more compelling a proposition if there were an example usage that fundamentally required the abstract-class approach (and couldn’t simply accept some parameters in `init`).

I do have some “fresh" concerns, however.

# Support For “Intermediate” Classes

As stated, it seems the proposal would force classes to be either or concrete; this is going to be limiting at times, and approaches like the below are often useful:

// fully-abstract
abstract class BaseClass  {
 
  abstract func someFunction()
  abstract func someOtherFunction()

}

// partially-abstract
abstract class IntermediateClass : BaseClass {

  override func someFunction() { /* implementation here */  }

}

// fully-concrete
class TerminalClass : IntermediateClass {

  override func someOtherFunction() { /* implementation here */ }

}

…although I could be mis-reading the proposal.

# Access Control Issues: Mixed OK, or Not?

Abstract classes and access control issues would need to be addressed. EG: is the below allowed, or not:

abstract public class ClassWithInternalAbstractMembers {

  // abstract members less visible than the containing type:
  internal abstract func someFunctionOnlyVisibleWithinThisModule()
  private abstract func someFunctionOnlyVisibleWithinThisFile()

}

…?

I think *not* is more consistent with how Swift generally works, but if *not* is chosen it has some awkward implications for how useful the feature is (see next point).

# Can’t Use Nicely For a “Closed" Class-Cluster

I personally think the strongest case for abstract classes is as an aide to building class-clusters, but there seem to be major issues doing this from Swift, especially if you are hoping for a “closed” class-cluster (e.g. one that isn’t meant for subclassing "from outside the module”). That is, it should meet the following bullet-points:

- there’s an abstract public base class (as the public-API)
- this public base class is de-facto final (not meant for “external” subclassing)
- there are some “private”, concrete subclasses (specialized in various ways, and all `final`)

…(noting that you wouldn’t always *want* a closed cluster, but sometimes you would…). 

One annoying issue here is that such a class-cluster can’t use `init`; even if we *could* have `init` return a subclass instance, the compiler would still presumably want to prevent us from “instantiating” an instance of our abstract class, and this seems awkward to really resolve…so we’re stuck with static factory functions (which will seem unnatural).

Most of the other issues I’d raise re really due to the lack of a way to say “this class/this method/etc. should be *treated* as final outside this module, even if it’s not actually `final` within the module”. But, without that kind of feature, it becomes hard to achieve a “de-facto `final`” approach, b/c:

- the abstract base class is public
- thus the abstract functions are also public (by no-mixed-visibility assumption)
- those methods can’t be marked final (we *need* to override them)
- thus we can’t achieve the closed-family (b/c the abstract methods are all public and non-final on a public and non-final class)

…which can be worked around if you keep all the *classes* module-internal and export, say, a public struct wrapper privately wrapping a class instance, but that’s getting pretty unwieldy and feels like it shouldn’t be necessary.

> 	• Is the problem being addressed significant enough to warrant a change to Swift?

I think it *exposes* a significant problem, but I’m not sure the fix is right.

> 	• Does this proposal fit well with the feel and direction of Swift?

It seems hard to fit into the rest of Swift in the details (e.g. the `init` issue, and the apparent lack of a satisfying way for the implementer to achieve a reasonable balance of visibility, overridability, and finality). 

> 	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

It seems broadly similar. 

> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Some thought, some observation of the discussion.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160226/c706e83f/attachment.html>