Неправильное предупреждение XCode "не реализует протокол X"

Question

В моем проекте у меня есть 3 класса, назовем их Apple, Orange и Pear.

Apple и Orange имеют свойства делегата.Они оба определяют протоколы в своем заголовочном файле, который называется AppleDelegate и OrangeDelegate.Каждый из них имеет инициализаторы с похожими сигнатурами:

- (id)initWithDelegate:(id<AppleDelegate>)delegate
- (id)initWithDelegate:(id<OrangeDelegate>)delegate

Pear реализует OrangeDelegate и определяется следующим образом:

@interface Pear : NSObject <OrangeDelegate>

Внутри Pear, я делаю этот вызов:

Orange *anOrange = [[[Orange alloc] initWithDelegate:self] autorelease];

Это приводит к предупреждению компилятора:

Class 'Pear' does not implement the 'AppleDelegate' protocol

Мне кажется, что компилятор не распознает протоколы в инициализаторах.Другими словами, он распознает эту подпись только для обоих:

- (id)initWithDelegate:(id)delegate

Потому что, когда я нажимаю «Перейти к определению» на инициализаторе в Pear, он вызывает оба класса как опции.

Есть ли способ исправить это предупреждение, кроме переименования моих методов?

Answer 1

Проблема в том, что «alloc» - это метод, унаследованный от NSObject, определенный для возврата типа «id». Итак, следующее:

[Orange alloc]

Оценивает объект типа 'id'. Когда вы затем вызываете initWithDelegate для этого объекта, компилятор не знает тип и в этом случае угадывает неправильный. Таким образом, вы можете устранить предупреждение с помощью:

Orange *anOrange = [[(Orange *)[Orange alloc] initWithDelegate:self] autorelease];

Так что, в основном, это потому, что конструкторы - это не функция уровня языка в Objective-C, а просто соглашение.

РЕДАКТИРОВАТЬ: см. Ниже; Я думаю, другое решение было бы добавить:

+ (Orange *)alloc;

Для Orange, который был бы не более сложным, чем:

+ (Orange *)alloc
{
    return [super alloc];
}

Я полагаю, что это отчасти является дизайнерским решением - если классы будут нести ответственность за знание того, что их методы конструктора могут конфликтовать с именами других классов, или если за устранение неоднозначности будут отвечать файлы, импортирующие несколько определений классов с одинаковыми конструкторами. Хотя простой взгляд на синтаксис может быть решающим.