Comments 37
А компилятор не предупреждает когда присваиваешь в BOOL какой-нибудь int?
Ворнинг будет. Но многие ли их читают? Увы, нет.
Ну накопление ворнингов в проекте — достаточно плохая штука. Мое мнение — увидел warning, попробуй устранить. Часто они на действительно серьезные проблемы же указывают. А тут совсем просто — сделал приведение типа и все…
По статье: для любого человека, мало-мальски читавшего официальную документацию она (статья) может показаться ну совсем уж капитанской =)
По статье: для любого человека, мало-мальски читавшего официальную документацию она (статья) может показаться ну совсем уж капитанской =)
Ну накопление ворнингов в проекте — достаточно плохая штука.
Я стараюсь их убивать на корню (с анализом «что не так», разумеется), да ещё и статическим анализатором регулярно прохожусь.
она (статья) может показаться ну совсем уж капитанской
О том же и я написал, чуть ниже =)
Приведение типа имеет тот же самый эффект. Обрежутся лишние байты и всё.
Вот тут: govnokod.ru/12177 интересное обсуждение вопроса возникло. Про nil/NULL/NSNull там на сайте тоже где-то было, кстати.
Вот тут: govnokod.ru/12177 интересное обсуждение вопроса возникло. Про nil/NULL/NSNull там на сайте тоже где-то было, кстати.
ну наверно они не программисты, раз ворнинги оставяют и не читают. это же бред.
"… системе времени выполнения"?
прошу поправить.
прошу поправить.
Статья простовата, ожидал большего. Мне кажется, было бы полезнее написать о литералах (и boxed-литералах), о mutable/immutable, о структуре класса в ObjC, о богатейшем рантайме.
Нормально, речь ведь идет о простых и интересных фактах а не о глубинных особенностях рантайма или синтаксическом сахаре, для этого лучше документация подходит.
Я, например, никогда не задумывался почему именно .m, или почему объявление методов начинается с "-" или "+". О соглашении насчет «get» тоже было интересно узнать.
Я, например, никогда не задумывался почему именно .m, или почему объявление методов начинается с "-" или "+". О соглашении насчет «get» тоже было интересно узнать.
Ведущее тире указывает, что это объявление метода Objective-C. Это тире предназначено для того чтобы отличить объявление метода от прототипа функции.
А я всегда думал что это для того чтобы отличить метод экземляра от метода класса, вот я дурак…
Поздравляю автора с тем что он осилил первую главу любого учебника по obj-c. Очередной пост ради поста от автора-рака.
Если что, есть материал пообъемней.
Вот вы написали про get/set — а кто мне мешает самому написать свой getter для любого объекта/переменной? И про @property/@synthesize не слова. Так же про .h вы умолчали а это тоже основа Objective-C (в части про import) что мы посылаем abstract reference методов класса.
Вот вы написали про get/set — а кто мне мешает самому написать свой getter для любого объекта/переменной?
Извиняюсь, не понял вопроса. Ни кто не мешает. Я написал: «Слово get в Cocoa имеет особый смысл: в имени метода Cocoa оно обозначает, что метод возвращает значение посредством указателя, переданного в качестве параметра.»
Поэтому не стоит его использовать в других случаях, если вы конечно не хотите запутать программистов, которые будут читать ваш код.
Хорошо я выражусь по другому — getter/setter почти во всех языках дает reference к адресу обьекта/параметра (pass-by-reference) против pass-by-value. У меня в этим проблем нету. Тока я говорю что это не совсем полное описания get/set — ведь get/set это modular methods в который @property/@synthesize входит как один из вариантов обращения к обьектам/параметрам.
Пардон, это mutator methods — не успел поменять
Да, написать можно было больше и конкретно про getter и setter, но мне показалась интересной информация о том где мы используем префикс get, хотя казалось бы логичным использовать его для getter'а. Возможно это не так важно как информация о @property/@synthesize, но я не ставил целью собирать важную информацию — она есть везде. Я хотел в одном месте собрать интересные и полезные факты.
К сожалению, на мой призыв добавить другие факты в комментариях ни кто не отозвался.
К сожалению, на мой призыв добавить другие факты в комментариях ни кто не отозвался.
А чем вам не интересный факт — не надо писать свои mutator methods и access через classIntance.reference (e.g. self.object)
Или как на счет sugar syntax для get?
#import
interface Photo: NSObject {
NSString* caption;
NSString* photographer;
}
— caption;
— photographer;
end
против
#import
interface Photo: NSObject {
NSString* caption;
NSString* photographer;
}
— (NSString*) caption;
— (NSString*) photographer;
end
Я знаю что первый возвращаем instance id method, но так писать то можно. (У меня таги source не работают так что пардон за такой стиль написания).
#import
interface Photo: NSObject {
NSString* caption;
NSString* photographer;
}
— caption;
— photographer;
end
против
#import
interface Photo: NSObject {
NSString* caption;
NSString* photographer;
}
— (NSString*) caption;
— (NSString*) photographer;
end
Я знаю что первый возвращаем instance id method, но так писать то можно. (У меня таги source не работают так что пардон за такой стиль написания).
исходник побило очень =\
Что Вы имеете ввиду под «компиляция типа налету»?
Что Вы имеете ввиду под «компиляция типа налету»?
У меня теги в комментариях не работают, еще раз извиняюсь.
Я иммел в виду runtime.
Когда делаем обращение к get в другом классе можно или так вызвать
NSString *ns = photoInstance.caption; // photoInstance.caption будет id, и в runtime id перебьет под NSString * и здесь уже чисто риск программиста а что же было такое id (компилятор пропустит).
или через cast
NSString *ns = (NSString *) photoInstance.caption; //cast в NSString *
Я иммел в виду runtime.
Когда делаем обращение к get в другом классе можно или так вызвать
NSString *ns = photoInstance.caption; // photoInstance.caption будет id, и в runtime id перебьет под NSString * и здесь уже чисто риск программиста а что же было такое id (компилятор пропустит).
или через cast
NSString *ns = (NSString *) photoInstance.caption; //cast в NSString *
Рантайм ничего не «перебьет». Обычное присваивание указателей. То что фактический тип остается на совести программиста — верно.
Кастовать id в любой другой тип смысла нет вообще, id по определению присваивается любому объекту без ворнинга и каста.
И еще, касты в Objective C, как и в C — только для успокоения компилятора. Никаких проверок типов при кастовании не происходит (в отличие например от каста в Java или dynamic_cast в C++). Но в случае id его даже «успокаивать» не надо.
И где тут аналогия со Scala? Там есть только compile-time вывод типа, в рантайме с типами ничего не происходит, jvm же.
Кастовать id в любой другой тип смысла нет вообще, id по определению присваивается любому объекту без ворнинга и каста.
И еще, касты в Objective C, как и в C — только для успокоения компилятора. Никаких проверок типов при кастовании не происходит (в отличие например от каста в Java или dynamic_cast в C++). Но в случае id его даже «успокаивать» не надо.
И где тут аналогия со Scala? Там есть только compile-time вывод типа, в рантайме с типами ничего не происходит, jvm же.
«перебьет» -> «superclass to subclass typecast» можно использовать как обозначание?
id — superclass, тоже что Object в Java.
И еще, касты в Objective C, как и в C — только для успокоения компилятора. Никаких проверок типов при кастовании не происходит (в отличие например от каста в Java или dynamic_cast в C++). Но в случае id его даже «успокаивать» не надо. — да вы правы, не знал. Тогда опять же — все на совести программиста.
pattern matching в Scala разве не runtime?
id — superclass, тоже что Object в Java.
И еще, касты в Objective C, как и в C — только для успокоения компилятора. Никаких проверок типов при кастовании не происходит (в отличие например от каста в Java или dynamic_cast в C++). Но в случае id его даже «успокаивать» не надо. — да вы правы, не знал. Тогда опять же — все на совести программиста.
pattern matching в Scala разве не runtime?
«перебьет» -> «superclass to subclass typecast» можно использовать как обозначание?
можно, но фактически в рантайме никаких дополнительных действий из-за каста не будет, как было присваивание указателя, так и останется.
id не суперкласс, id — «магический тип», которому можно слать любые сообщения и присваивать любым объектным переменным без каста (проделайте-ка тоже самое с Object в Java).
Суперкласс один — NSObject.
Ну в ходе patterin matching'а наверное могут осуществляться проверки instanceof и касты, да.
id не суперкласс, id — «магический тип», которому можно слать любые сообщения и присваивать любым объектным переменным без каста (проделайте-ка тоже самое с Object в Java).
Век живи веч учись — спасибо, буду знать. Да про Java знаю, я с нее начинал.
В Scala кажеться вот в этом случии тоже в runtime x получает :Int
type Set = Int => Boolean
def union(s: Set, t: Set): Set = x => s(x) || t(x)
Век живи веч учись — спасибо, буду знать. Да про Java знаю, я с нее начинал.
В Scala кажеться вот в этом случии тоже в runtime x получает :Int
type Set = Int => Boolean
def union(s: Set, t: Set): Set = x => s(x) || t(x)
всегда думал что .m — это "(m)odule" или «i(m)plementation», а оказывается вот оно что.
Все намного проще — Брэд Кокс (создатель Objective-C) на вопрос от причинах выбора расширения ".m" ответил так:
«Because .o and .c were taken. Simple as that.»
Sign up to leave a comment.
Полезные факты о языке программирования Objective-C