ios - UIBezierPath Subclass Initializer

Question

I'm trying to create a subclass of UIBezierPath to add some properties that are useful to me.

class MyUIBezierPath : UIBezierPath {
   var selectedForLazo : Bool! = false

   override init(){
       super.init()
   }

   /* Compile Error: Must call a designated initializer of the superclass 'UIBezierPath' */
   init(rect: CGRect){
       super.init(rect: rect)
   }

   /* Compile Error: Must call a designated initializer of the superclass 'UIBezierPath' */
   init(roundedRect: CGRect, cornerRadius: CGFloat) {
       super.init(roundedRect: roundedRect, cornerRadius: cornerRadius)
   }

   required init(coder aDecoder: NSCoder) {
       fatalError("init(coder:) has not been implemented")
   }
}

EDIT: I need this because in my code i write

var path = MyUIBezierPath(roundedRect: rect, cornerRadius: 7)

and it results in a compile error:

"Must call a designated initializer of the superclass 'UIBezierPath'"

I tried to add that initializers in the subclass but it seems not to work.

Can you help me please?

Answer 1

NOTE: This problem is solved in iOS 9, where the API has been rewritten so that init(rect:) exists, and so do all the others, as convenience initializers, as they should be.

---

The Problem

In a nutshell, the problem you're experiencing is that the following code does not compile:

    class MyBezierPath : UIBezierPath {}
    let b = MyBezierPath(rect:CGRectZero)

From the Swift point of view, that seems just wrong. The documentation appears to say that UIBezierPath has an initializer init(rect:). But then why isn't UIBezierPath's init(rect:) being inherited in our subclass MyBezierPath? According to the normal rules of initializer inheritance, it should be.

The Explanation

UIBezierPath is not intended for subclassing. Accordingly, it doesn't have any initializers - except for init(), which it inherits from NSObject. In Swift, UIBezierPath looks as if it has initializers; but this is a false representation. What UIBezierPath actually has, as we can see if we look at the Objective-C headers, are convenience constructors, which are class methods, such as this:

+ (UIBezierPath *)bezierPathWithRect:(CGRect)rect;

Now, this method (along with its siblings) demonstrates some unusual features that Swift does not deal with very well:

• It is not merely a variant of an initializer; it is a pure convenience constructor. Objective-C shows us that UIBezierPath has no corresponding true initializer initWithRect:. That's a very unusual situation in Cocoa.

• It returns UIBezierPath*, not instancetype. This means that it cannot be inherited, because it returns an instance of the wrong type. In a subclass MyBezierPath, calling bezierPathWithRect: yields a UIBezierPath, not a MyBezierPath.

Swift copes badly with this situation. On the one hand, it translates the class method bezierPathWithRect: into an apparent initializer init(rect:), in accordance with its usual policy. But on the other hand, this is not a "real" initializer, and cannot be inherited by a subclass.

You have thus been misled by the apparent initializer init(rect:) and then surprised and stumped when you could not call it on your subclass because it isn't inherited.

NOTE: I'm not saying that Swift's behavior here is not a bug; I think it is a bug (though I'm a little hazy on whether to blame the bug on Swift or on the UIBezierPath API). Either Swift should not turn bezierPathWithRect: into an initializer, or, if it does make it an initializer, it should make that initializer inheritable. Either way, it should be inheritable. But it isn't, so now we have to look for a workaround.

Solutions

So what should you do? I have two solutions:

• Don't subclass. Subclassing UIBezierPath was a bad idea to start with. It is not made for this sort of thing. Instead of a subclass, make a wrapper - a class or struct that, rather than having the feature that is a UIBezierPath, has the feature that it has a UIBezierPath. Let's call it MyBezierPathWrapper:

  struct MyBezierPathWrapper {
      var selectedForLazo : Bool = false
      var bezierPath : UIBezierPath!
  }
  

  This simply couples your custom properties and methods with a normal UIBezierPath. You could then create it in two steps, like this:

  var b = MyBezierPathWrapper()
  b.bezierPath = UIBezierPath(rect:CGRectZero)
  

  If that feels unsatisfactory, you can make this a one-step creation by adding an initializer that takes the UIBezierPath:

  struct MyBezierPathWrapper {
      var selectedForLazo : Bool = false
      var bezierPath : UIBezierPath
      init(_ bezierPath:UIBezierPath) {
          self.bezierPath = bezierPath
      }
  }
  

  And now you can create it like this:

  var b = MyBezierPathWrapper(UIBezierPath(rect:CGRectZero))
  

• Subclass with a convenience constructor. If you insist on subclassing, even though UIBezierPath is not intended for that sort of thing, you can do it by supplying a convenience constructor. This works because the only important thing about a UIBezierPath is its CGPath, so you can make this convenience constructor a copy constructor merely transferring the path from a real UIBezierPath:

  class MyBezierPath : UIBezierPath {
      var selectedForLazo : Bool! = false
      convenience init(path:UIBezierPath) {
          self.init()
          self.CGPath = path.CGPath
      }
  }
  

  Now we can create one very similarly to the previous approach:

  let b = MyBezierPath(path:UIBezierPath(rect:CGRectZero))
  

  It isn't great, but I think it's marginally more satisfying than having to redefine all the initializers as your solution does. In the end I'm really doing exactly the same thing you're doing, in a more compressed way. But on balance I prefer the first solution: don't subclass in the first place.