Нет ivars - ›Что мне не хватает?

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

Примечание: я полагаюсь исключительно на ivars, которые автоматически добавляются (компилятором?) Для объявления свойства.

Не закрывать: Я рассмотрел некоторые другие вопросы, например this и this, и ни один из них не попал в точку. Заголовки выглядят хорошо, но, как и многие вопросы по SO, вопросы представляют собой беспорядок странных сомнений и прочего.


ios objective-c automatic-properties
person Dan Rosenstark    schedule 14.09.2011    source источник
comment
См. stackoverflow.com/questions/6112283/question-about-synthesize/ Существуют различия в поведении синтеза средств доступа, которые зависят от среды выполнения ... Использование @property и ручное объявление ivars полезно только для поддержки устаревшей среды выполнения (afaik).   -  person Jano    schedule 14.09.2011
comment
@Jano, уместен ли этот длинный ответ? Если да, то как? Понятно, что свойства используют аксессоры, и в этом разница между self.thing = that и thing = that. Так?   -  person Dan Rosenstark    schedule 14.09.2011
comment
Ой, мне очень жаль, что я прочитал долго. Я только хотел указать вам на цитату из Директивы реализации свойств, в которых говорится, что синтез выполняется во время компиляции. Я не могу понять, как использовать свойства ivars вместо свойств в современной среде выполнения. Это интересный вопрос, я рассмотрю его подробнее.   -  person Jano    schedule 15.09.2011
comment
Просто подумайте: можно ли добиться эффекта всех директив компилятора области (@private и т. Д.) С помощью свойств? Я знаю readonly и readwrite, но могут ли они (возможно, с помощью расширений классов) охватить все необходимые области?   -  person Stuart    schedule 15.09.2011
comment
@StuDev, @private достаточно легко имитировать, но @protected уже сложнее (как заставить подклассы использовать расширение класса, а другие классы игнорировать его?). Итак, я думаю, вы подошли к началу очень интересного ответа. К сожалению, этот вопрос не подхватили 63 тысячи горилл, которые могли ответить на него без каких-либо поисков в Google или исследований, так что это мы.   -  person Dan Rosenstark    schedule 15.09.2011
comment
@Yar, после небольшого исследования, я думаю, что собираюсь опубликовать это в качестве ответа ... похоже, нет способа объявить свойство, которое рассматривается как защищенное.   -  person Stuart    schedule 15.09.2011

Ответы (3)


arrow_upward
4
arrow_downward

Объявленные свойства не могут обрабатываться так же, как @protected ivar. Вы можете объявить свойство в расширении класса, чтобы сохранить его частным от любого другого класса, или объявить его в интерфейсе заголовка, чтобы сделать его общедоступным, однако нет способа сделать его доступным только для подклассов. Для этого потребуется декларация ivar.

ИЗМЕНИТЬ

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

Например, предположим, что вы вызываете некоторый код в замкнутом цикле и хотите убедиться в его работоспособности. Внутри этого плотного цикла вы хотите получить доступ к свойству класса, но вам нужно знать, вычисляется ли возвращаемое значение каждый раз при его вызове на лету или сохраняется в iVar. Просмотр iVar в заголовке - быстрый способ убедиться, что вы вернете эту переменную без особых накладных расходов.

person Stuart    schedule 15.09.2011
comment
Примечание. Если я не ошибаюсь - stackoverflow .com / questions / 1933438 / - даже @protected или @private можно сделать общедоступным через категории. Ваша точка зрения по-прежнему актуальна и интересна, но похоже, что смерть сбивающего с толку iVars наступит не скоро. - person Dan Rosenstark; 15.09.2011
comment
@Yar: Да, похоже, что это не так. Objective-C, кажется, известен тем, что дает достаточно веревки, чтобы повеситься, но с множеством простых низких заборов, которые предупреждают вас, чтобы вы не подходили слишком близко к виселице (извините за ужасную метафору). На самом деле мне очень нравится эта идея, но проблемы возникают, когда вы начинаете случайно переопределять вещи, которые не следует переопределять. Хотя я действительно думаю, что разработчики Mac и iOS, вероятно, «воспитаны» в защитном коде и следуют соглашениям до такой степени, что в большинстве случаев эти подводные камни не являются большой проблемой. - person Stuart; 16.09.2011
comment
отличный комментарий, без метафор. Эмпирические факты говорят о том, что на Obj-C создаются отличные приложения, несмотря на то, что повсюду лежат нелепые мины. На самом деле, похоже, это, возможно, отсеивает некоторых дебилов. Лично я придумал более защищенные от идиотов языки, такие как Java (я проигнорирую хихиканье), но, возможно, с глобальной точки зрения защищенные от идиотов языки, которые облегчают вашу работу, возможно, хуже. - person Dan Rosenstark; 16.09.2011
comment
@yar Вы так правы насчет обоюдоострого / высокого барьера для входа. objc искренне выглядит и чувствует МЕССОР даже для самого умного человека - сначала, потом, и так далее - за МНОГИЕ взгляды. Пока этого не произойдет. Я действительно сомневаюсь, что у большинства идиотов хватит терпения придерживаться чего-то такого странного и глупого ... Сначала .... - person Alex Gray; 05.04.2012

arrow_upward
3
arrow_downward

Я не вижу смысла использовать iVars, если вам это не нужно. Если Apple и компилятор хотят работать за вас, я говорю: позвольте им. У вас будет более эффективный и простой в обслуживании код. На данный момент iVars - это устаревший код.

person SSteve    schedule 14.09.2011
comment
Спасибо @SSTeve, я так думаю (это было так очевидно), но я с нетерпением жду некоторых несогласных по этому поводу. - person Dan Rosenstark; 14.09.2011
comment
Интересно, поэтому, когда вы создаете новый подкласс, шаблонный код Apple для объявления @interface больше не включает фигурные скобки для объявлений iVar ...? Должен признаться, я всегда сам включал iVars, но, прочитав этот вопрос, я даже не знаю почему! - person Stuart; 14.09.2011
comment
@StuDev, не расстраивайтесь: разработчики, которые следуют правилам / соглашениям (даже если они не имеют смысла), в конечном итоге, как правило, сталкиваются с меньшим количеством проблем. Но да, ИМО, именно поэтому Apple избавилась от фигурных скобок, но это не значит, что вы можете просто спросить Apple. Я уверен, что где-то в какой-то момент WWDC какой-нибудь случайный разработчик, вероятно, упомянет об этом. - person Dan Rosenstark; 14.09.2011
comment
Я уверен, что шаблоны эволюционировали, чтобы стимулировать использование @properties, которые предлагают несколько преимуществ по сравнению с ivars. Я так понимаю, Яр просто ищет угловые случаи. Неофициально в cocoa-dev есть несколько разработчиков Apple, но никто не назначен для этого. - person Jano; 15.09.2011

arrow_upward
1
arrow_downward

Одна веская причина для меня: раздражающая ошибка GCC, см. этот другой вопрос для описания.

Если вы используете Clang / LVVM, вам не нужно беспокоиться об этой ошибке.

person jv42    schedule 15.09.2011
comment
1) Нет, я столкнулся с этой ошибкой на iOS. 2) Отладчик - это GDB, который (на самом деле) не имеет отношения к GCC. - person jv42; 15.09.2011