Comments 20
Вот такие базовые вещи порой ускользают так как ты считаешь их обыденными и используешь по наитию. А если спросят на собеседовании вопрос вроде: «почему переменные типа id объявляются без *?» не знаешь как ответить и уже после такого вопроса начинаешь разбираться в вещах которые ты вроде бы знал.
Продолжайте.
Продолжайте.
имхо чудовищный вариант сеттера: isEqual, release до retain
и про atomic тоже неправда
не надо ничего выдумывать, надо просто раскурить ман
Спасибо за комментарии. Действительно, сеттер был не примером для подражания. Поправил. С atomic тоже немного уточнил формулировку, но в целом, не совсем понятно, что именно, по Вашему мнению, там неправда. Добавьте и сюда конструктива, пожалуйста, — укажите, с чем именно Вы не согласны.
Про atomic по-моему было написано совсем не так как сейчас, потому что к нынешнему варианту мне уже сложно придраться. А может я вчера плохо прочитал.
Я вообще не очень хорошо представляю себе реальный случай необходимости atomic, разве что при использовании больших структур, типа
struct MyStruct {
int integers[100];
double doubles[100]
};
Как я понимаю, здесь atomic обеспечит полную запись и полное чтение, т.е. не будет ситуации когда один поток прочитал или записал одну половину, а второй-вторую. В случаях с указателями atomic имхо не актуален.
Призываю знающих людей, кто действительно хорошо понимает что это такое и может объяснить на простом примере, а то я тут сейчас нарассказываю :)
Я вообще не очень хорошо представляю себе реальный случай необходимости atomic, разве что при использовании больших структур, типа
struct MyStruct {
int integers[100];
double doubles[100]
};
Как я понимаю, здесь atomic обеспечит полную запись и полное чтение, т.е. не будет ситуации когда один поток прочитал или записал одну половину, а второй-вторую. В случаях с указателями atomic имхо не актуален.
Призываю знающих людей, кто действительно хорошо понимает что это такое и может объяснить на простом примере, а то я тут сейчас нарассказываю :)
На вкус и цвет. Пол Хэгарти, например, считает это очень хорошо.
а Алексей Сторожев на своей заднице прочувствовал креши из-за того, что _foo и foo это один и тот же объект
справедливости ради, там сначала проверка ![_foo isEqual:foo] идет. Но всё равно code smell.
А разве не бывает такого, что [x isEqual:x] == false? И вообще здесь не место isEqual по-умолчанию, логика бывает завязана не только на объект как значение, но и на объект как указатель. Можно придумать кучу примеров, демонстрирующих почему isEqual тут не первичен.
Я считаю что это нарушение контракта -isEqual:, но так как для Cocoa он явно нигде не прописан (в отличие от Java), вопрос открытый.
Всё же это вопрос восприятия и привычки. Т.е., я акцентирую на этом внимание только, когда акцентируют на этом моё внимание) В остальных случаях всё понятно.
Уже давно вышел Xcode 6, не за горами уже Xcode 7, а в Вашей статье про Nullability атрибуты — ни слова. Ну как же так?
Не упомянуты nullability annotations здесь потому, что imho к свойствам они относятся скорее «заодно», чем «в первую очередь». Да еще, рассказывая про них, надо бы и Swift приплетать. Думаю, хорошенько покопавшись, так можно к этой статье еще много чего привязать. Но я уверен, что не стоит все собирать в одном месте, как не стоит писать классы на 70к строк
Я уважаю Ваше мнение, но, как Вы написали, статья для новичка. Новичок, прочитав ее, даже не будет знать что такое
Данная фраза подразумевает, что вы перечислили все варианты свойств, что уже вводит в заблуждение. А знание об этих атрибутах поможет защитить себя от ошибок в коде, а также поможет выработать хороший стиль программирования. И, как мне кажется, вполне можно обойтись и без упоминания Swift — он тут совсем не обязателен.
@property(..., nullable), не говоря уже о null_resettable. Также, цитируя Вас:Для начала поделим все атрибуты, которые есть у свойства, на группы:
Данная фраза подразумевает, что вы перечислили все варианты свойств, что уже вводит в заблуждение. А знание об этих атрибутах поможет защитить себя от ошибок в коде, а также поможет выработать хороший стиль программирования. И, как мне кажется, вполне можно обойтись и без упоминания Swift — он тут совсем не обязателен.
Эх, где вы были с данной статьей года 2 назад =)
Objective-C в принципе дался мне достаточно тяжело, прежде чем написать первый готовый проект я раза 2 бросал это занятие, отчасти из-за таких непонятных мелочей.
Objective-C в принципе дался мне достаточно тяжело, прежде чем написать первый готовый проект я раза 2 бросал это занятие, отчасти из-за таких непонятных мелочей.
Почему, стоит лишь у одно свойства прописать nonnull, как Xcode тут же выписывает предупреждения
по всем остальным свойствам класса? Почему ему недостаточно «null_unspecified — используется по умолчанию»?
Pointer is missing a nullability type specifier (__nonnull or __nullable)
по всем остальным свойствам класса? Почему ему недостаточно «null_unspecified — используется по умолчанию»?
Sign up to leave a comment.
Атрибуты свойств в Objective-C. Инструкция для начинающих