Pull to refresh

Comments 7

- (void)forwardInvocation:(NSInvocation *)invocation
{
    [invocation invokeWithTarget:self.instance];
}


В таком случае лучше использовать -forwardingTargetForSelector::

- (id)forwardingTargetForSelector:(SEL)aSelector
{
    return self.instance;
}
Да, согласен полностью.
UIAppearance — насколько мне известно — единственное использование NSProxy в базовых iOS фреймворках

Какая связь между UIAppearance и NSProxy?
Если я не ошибаюсь, именно об этом пишут в документации, да и поведение весьма напоминает отложенный форвардинг.
Proxy и NSProxy это не одно и тоже)

(lldb) po [[[UIView appearance] class] superclass]
NSObject


Да и зачем ему NSProxy?
Хм… Проверил [UIButton appearance].isProxy — False. Так что вы правы, моя ошибка) Забавно, очень гармонично ложится на такую функциональность как раз NSProxy.
Спасибо за исправление!
Просто у вас получилось все в куче. Проксирование не всегда подразумевает использование NSProxy.

Прокисирование в Cocoa реализуется при помощи Message Forwarding, для этого у NSObject есть methodSignatureForSelector, forwardInvocation и другие.

Но если объект имплементирует какой-то селектор, то до форврадинга не дойдет. И если в качестве базового класса для прокси брать NSObject, то часть методов не проксируется (init, performSelector, ...). (конечно можно извратиться и переопределить эти методы в классе прокси, например руками или в runtime, но это слишком утомительно)

А если не NSObject, то что?! Свой root-класс просто не сделать, так как нужно имплементировать alloc и протокол NSObject.

Поэтому инженеры Apple добавили еще один root-класс (NSProxy), который имплементирует минимальное количество селекторов, и следовательно может проксировать почти всё.

Sign up to leave a comment.

Articles