Protocol Inheritance - Function Type Override

Question

Created Jan ’16

Replies 1

Boosts 0

Participants 1

I would like a 'child' protocol to override the types of one of the 'parent' functions. Like this:

protocol Delegate {}

protocol Thing {
  func handle (delegate:  Delegate)
}

protocol OtherDelegate : Delegate {}

protocol OtherThing : Thing {
  func handle (delegate: OtherDelegate)  // requires OtherDelegate, not Delegate
}

If I then implement `OtherThing` with:

class StandardOtherThing : OtherThing {
  // ...
}

It requires implementations of two `handle` functions - one for `Delegate` and one for `OtherDelegate`. It should be an error to pass `OtherThing` just a plain old `Delegate`; `OtherDelegate` is required. Can't I catch this before runtime?

If instead I try parameterizing `handle` as

protocol Thing {
  func handle<D: Delegate> (delegate:  D)
}

protocol OtherThing : Thing {
  func handle<D: OtherDelegate> (delegate:  D)
}

still no dice, the `OtherThing` requires two methods.

I know that I can use:

protocol Entity {
  typealias D : Delegate
  func handle (delegate: D)
}
protocol OtherEntity : Entity {
  typealias D : OtherDelegate
}
class StandardOtherEntity<DD : OtherDelegate> : OtherEntity {
  typealias D = DD
  func handle(delegate: DD) {}
}

but the above introduces an 'Associated Type' constraint - which doesn't allow me to 'mixin' the Delegate protocol - I have to create a `StandardOtherEntity` with a specific subtype of `OtherDelegate`

Boost

Answer 1

GoZoner OP

Jan ’16

The 'solution' to my `Entity-with-assocated-type-constraint` is to use the AnySequencing-approach?

struct AnyOtherDelegate : OtherDelegate {
 var base : OtherDelegate
 // implement OtherDelegate using base
}

And then concretizing `StandardOtherEntity` as:

class StandardOtherEntity : OtherEntity {
 typealias D = AnyOtherDelegate
 func handle (delegate: AnyOtherDelegate) {}
}

And then a 'user' would be implemented with:

class RandomUser : OtherDelegate {
 func run () {
   handle (AnyOtherDelegate(base:self))
 }
}

Is this the (evolving) Swift-y approach?

0