Шокирующий Objective-C для Java программистов

[bobermaniac]

На самом деле, смысла в описании различий синтаксиса нет никакого — понимание приходит через две недели работы, а начинать писать можно сразу же после прочтения статьи о языке в википедии.

А вот различия в семантике — особенно работа со счетчиком ссылок (assign/retain-init-copy, autorelease pool), категории и подстановки первое время серьезно бьют по мозгам.

Хотя уже через месяц вырабатываются практики использования всех этих возможностей для эффективного программирования. Правда, программисты на C# по инерции продолжают использовать категории в качестве партиальных классов.

[sadgb]

Используйте ARC и забудьте про счетчик ссылок =)

[symorium]

а также забудьте о поддержке версий < 5.0 :)

[sadgb]

вас бы за это заминусовать до -100 чтобы никто не видел. Проекты с ARC прекрасно работают даже на 3х
ARC это функция компилятора а не ОС — учите матчасть

[sadgb]

4.3x имелось в виду

[symorium]

Ой, я конечно же имел ввиду ios 4.0, ведь поддержка идет с xcode 4.2 для ios >= 4.0. А вот на счет 3х — не правда.

[igofed]

Странно. Я вот C# разработчик и не использую так категории.
И уж пошла речь о них:
Partial class в C# — это совсем другое. А вот методы расширения — один в один категории.

[bobermaniac]

Вы особенный.

[kent44]

По сути это нечто среднее между partial и extension. Partial — всего лишь одно из применений категорий. И C# тут не при чем: много классов в самом Foundation Kit используют категории в качестве Partial.

[ScratchBoom]

*shoked*

[BurundukXP]

когда-то начинал писать подобную серию статей для C# разработчиков, но после первого поста забросил — Objective-C для C# разработчиков
ваш подход «через шок» мне кажется интереснее.
<мысливслух>может тоже стоит возобновить и таки дописать этот предполагаемый цикл.</мысливслух>

[dimitrymd]

Было бы очень интересно почитать дальше.

[BurundukXP]

спасибо. попробую продолжить.

[graycrow]

Да, пожалуйста продолжайте.

[BurundukXP]

приятно, что статья оказалась полезной:) в ближайшее время напишу продолжение.

[dokwork]

Казалось бы, что может быть интересного в сравнении синтаксисов двух языков… Но автору удалось удержать мое внимание до конца статьи и просить продолжить в том же духе. Наверное, если бы пришлось изучать Objective-C, статья не вызвала бы интереса, но для общего развития посмотреть в «чужой огород» было интересно. Спасибо. (сам пишу на java)

[egormerkushev]

Когда я осваивал Objective-C, я был до смерти запуган подобными статьями. Теперь же могу сказать, что такие статьи — зло, а Obj-C я очень люблю.

[hashmap]

Мобильная версия чуть промахивается, повторю — мне он тоже нравится, см последний пример

[egormerkushev]

Просто новички (по себе сужу), больше внимания обращают не на объективные плюсы, а на часто саркастические пугающие комментарии к примерам и постам.

[SilentBrain]

Лично я на комменты не обращаю внимание, тут фишка в другом. Не могу сказать, что я полиглот, но языков программирования знаю достаточно. Objective-C начал учить недели 3 назад по Kochan S. Programming in Objective-C 2.0 и сразу испугало объявление интерфейса:
@interface Fraction: NSObject
{
int numerator;
int denominator;
}
-(void) print;
-(void) setNumerator: (int) n;
-(void) setDenominator: (int) d;
@end

Ну все-таки привык, когда "}" закрывает описание интерфейса/класса, а тут она закрывает только описание полей.
Сообщения, типа [fraction print] тоже убили… Сразу вспомнил статью про приставку «http://», когда разработчики стандарта говорили, что не подумали о возможной популярности протокола и может пользователи не набирали бы так много лишних символов (как-то так, не могу эту статью найти). Так и тут, выразительности ноль, зато есть много лишних элементов синтаксиса.

[Agent_Smith]

все эти «лишние» элементы синтаксиса отлично сам вставляет XCode

[SilentBrain]

Но читает же программист? Или тоже XCode?

[izen]

про какие лишние элементы синтаксиса вы говорите? @end? @interface? }?

[Agent_Smith]

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

[SilentBrain]

Привыкнуть можно, но Стив Джобс явно не приложил руку к Objective-C ) Все могло быть проще и красивее.

[bobermaniac]

Все-таки по современным меркам objective C — довольно уродливый язык. А без блоков он был бы еще и убогий.

Отсутствие обобщений довольно сильно угнетает, например. Зато встроенные примеси — это прекрасно, хотя по качеству они недалеко ушли от extension methods в C#.

[egormerkushev]

Ну не знаю. С точки зрения синтаксиса — мне лично более симпатичен, чем знакомые С++ или JavaScript (хоть это и скриптовый язык, но мы же про синтаксис).

[bobermaniac]

С-подобные языки лично мне более симпатичны, нежели smalltalk-образные. Хотя мне, определенно, нравится их идея построения объектной модели.

[markhor]

Некоторые считают, что extension methods — зло http://habrahabr.ru/blogs/net/122320/

[bobermaniac]

Некоторые до сих пор считают, что писать ресурсоемкие модули нужно на ассемблере. Не надо ориентироваться на девиации.

[hashmap]

Мне он тоже нравится, см последний пример

[egormerkushev]

В плане схожего синтаксиса последнее время меня очень манит Objective-J – Cappuccino

[general]

Практика «под каждую задачу свой язык» — хороша. Но «под каждую платформу свой язык» — имхо, перегиб.

[egormerkushev]

А причем тут Cappuccino?

[general]

Re: «В первом случае мы, конечно, получим NullPointerException и, возможно, увольнение. Во втором — в howManyHands будет возвращено 0. Это не 1, как мы ожидали, но хоть не уволили»
Это очень большой минус. Представим себе аналогичное поведение в Java: NullPointerException никогда не бросается. И бегай потом с дебаггером по всему коду и ищи почему он не работает.

[TRIMER]

Это огромный плюс. Как Objective-C разработчик говорю — никаких проблем с отладкой.
Плюсы очевидны:
1 Мне не надо совать кучу проверок на nil и тд -> код меньше и проще
2 Если указатель был nil я знаю что я всегда получу (0, nil, NO и тд) и на этом строитятся много кода
3 Снижается шанс, что программа упадет если все таки проверка где-то забыта или nil появился там где его не ожидали

[mokus]

Как Objective-C разработчик говорю — отсутствие NullPointerException — рассадник ошибок. Да, к этому привыкаеш, но тому кто это придумал я б гвоздь в голову забил.

[iStyx]

А вы не путаете nil и NULL? nil — это полноценный объект, которому (сюрприз!) можно послать любое сообщение.

[GreyWind]

Да ты что? Найди определение nil и NULL, а потом смотри разницу.

[sadgb]

ой да какой рассадник ошибок? мне вот только помогает — например при отправке сообщения делегату не надо смотреть существует он или нет

[izen]

3 года. Конечно в сообшениях в nil есть удобство при написании кода, но было бы лучше если бы была возможность отследить посылку сообшения в nil. Или если бы результатов сообшения от nil было какое то специфическое значение, а на 0.

[mokus]

)))
Победитель Game of The Year for iPad в этом году — моя игра Contre Jour. написана на objc конечно.
Не пропало желание опытом мериться?

[mokus]

да. я прогер с опытом.
я это не считаю проблемой. Я считаю это полнейшым профтыком разработчиков языка.
посмотрите в инете видео contre jour. оцените сложность. и вам все станет понятно.

[mokus]

А какая разница, сколько я программирую? (3 года на objc если уж так интересно)
Мастерство не в месяцах измеряется. Я делаю крутые и сложные вещи.
Я знаю сколько времени у меня уходит на отлавливание багов, связаных с nil. У вас нет? Так может вы просто делаете примитивные проекты?

[Mezomish]

Сложность проекта и количество строк кода — величины весьма слабо связанные.

[izen]

лол что? отловить сообщение нилу можно только переопределением obj_msgSend или навешиваним на нее проба в DTrace.

[mokus]

У вас какоето непреодолимое желание мерить все сантиметрами. Опыт в годах, сложность в строчках. Сложность в строчках не измеряется.
Дайте линк на какой-то свой проект и по описанию функционала будет видно сложный ли он.
method_exchangeImplementation — и к чему вы это??
Можно попробовать оверрайднуть obj_msgSend, но что тогда делать со всеми подключаемыми библиотеками, которые на такое поведение расчитывают?

[mokus]

цитирую свой предыдущий комент (вы его читали?)
>но что тогда делать со всеми подключаемыми библиотеками,
>которые на такое поведение расчитывают?

[mokus]

из того что я накопал я сделал вывод, что реплейснутый метод будет вызываться для всех библиотек.

а добавлять все классы каждой подключеной либы в блеклист… вы это действительно считаете приемлемым решением?

вообще для себя я нашел решение намного проще. следующие иОС проекты буду писать на моно. быстрее, удобнее и общяя код база для иОС, андроида и винфона.

[mokus]

mono уже врядли запретят — довольно популярные приложения на нем есть в сторе.
в WP7 не факт что плюсы добавят, да и пишу я под него уже прямо сейчас.
да и в плане скорости и удобства разработки C# всетаки намного привлекательнее чем C++. + следующий проект у меня возможно будет на Unity, а там опять C#.
Это не правило, конечно, но конкретно в моем случае mono выглядит очень хорошим решением.

[izen]

Лучшее решение этой проблемы это использование DTrace probe. Проб можно повесить на вызов obj_msgSend и настроить так чтобы он сообшал при вызове с нилом.

[mokus]

А до того я еще года 4 программировал на AS2, где аналогичное поведение null. И вздохнул с облегчением, когда из AS3 эту «фичу» убрали. И это несмотря на то, что AS2 вообще для меня был первым языком, на котором я работал.
Так что это явно не дело привычки.

[izen]

Задача разработче состоит не втом, чтобы написать программу которая не падает, а в том, чтобы написать программу которая работает. Иногда такая особенность как посылка сообшения в nil может быть причиной ошибок.

[TRIMER]

Большинству пользователей не будет дела до того как она работает, если периодически она будет вываливаться.

[izen]

Тоесть будет хуже если она будет неправильно реализовывать логику необходимую пользователю?) А если ваша программа падает/не падает, это не недостаток/преимущество языка, это мера вашей кривокукости)

[TRIMER]

Кто сказал, что она будет работать не правильно? Мой опыт говорит, что поведение nil больше плюс, чем минус, и статистикой (говорю только за себя) это подтверждается

[izen]

Я сказал :) Возмем пример

— (long long)someCalculations;

ваш код расчитывает, что метод вернет или 0 или кактой значение, так же?
А что по вашему вернет метод при посылке сообшения в nil? Подумайте над этим)

Я не говорю, что сообшения в nil это вселенское зло, но это потенциальный источник проблем, а удобств он дает самую малось)

[izen]

извиняюсь на счет long long метода был не прав, уже пофиксили ) Раньше метод бы вернул не 0, а числовое представление селектора, но это было во времен 32 битного кокоа.

[izen]

В 64 битном окружении проблем стало меньше) но опять же никто не отменял некоретного поведения основанного на nil, примет:

FireDetector *detector = [Detectors getDetector:kFireDetector];

//Предположим что по какой то ошибке в коде фабрика возврашает нам nil, какого поведение нашего кода в случае пожара?)

if ([detector isFire]) {
[self alarm];
}

[izen]

тада, я что то не очень удачный пример привел, но в целом это показывает возможные последствия от нила

[egormerkushev]

Вы просто со своей колокольни смотрите на это.

[bobermaniac]

Я со своей колокольни iOS-разработчика смотрю точно так же.

Конечно, замечательно, что в язык встроен патерн null object, нередко это бывает очень полезно. Но я бы все-таки хотел, чтобы реализация его была явной, например в виде [SomeObject nilInstance]

Единственное, что действительно приносит определенную пользу — это не падающий [nil release]

[egormerkushev]

Я не гуру, конечно, но почему рекомендуют делать так, аргументируя, что типа так безопаснее?
[name release];
name = nil;


[bobermaniac]

Дело в том, что после [name release] в переменной name остается адрес уже мертвого объекта. Любое обращение к этому объекту выдает SIG_BAD_ACCESS, который потом долго придется отлавливать с помощью NSZombie и прочих эзотерических практик.

[bobermaniac]

Две поправки — потенциально мертвого (если ваш release уменьшил счетчик ссылок до 0 и вызвал dealloc) и EXC_BAD_ACCESS.

[egormerkushev]

Да, я это и имел ввиду.

[egormerkushev]

Ну вот. Получается, что без этого `name = nil;`в Obj-C получим результат как в Java с ним, как написал general?

[bobermaniac]

Не совсем. EXC_BAD_ACCESS это все-таки не совсем обращение к нулевому указателю.

Кроме того, возможно, что в переменной name будет живой объект, если ссылка на него существует еще где-то. В этом случае мы получим просто неверное поведение.

[Flanker_4]

Да, что бы обезопасить себя.
Яркий пример касается uiviewcontrollera
Не гарантируется, что метод viewDidUnload будет вызван, а в нем рекомендуется освобождають ui шные переменные. В то же время, dealloc точно будет вызван. Что бы не возникла ситуация с утечкой памяти релизят и в методе viewdidunload и в dealloc. При этом если зарелизиться в viewdidload и переменной будет присвоенно nil, то в dealloc еще один realese к нилу пройдет незаметно.

[TRIMER]

Вы о чем? viewDidUnload не вызывается при удалении. Для освобождения ресурсов при удалении объекта только dealloc.

viewDidUnload метод для реакции на некоторые особые ситуации. Например, сообщение low memory warning. В этом методе рекомендуется освободить
все IB объекты и все, что потом легко восстановить в методе viewDidLoad (если вызван viewDidUnload то точно будет вызван повторно viewDidLoad, если объект раньше не удалят).

Пример с low memory warning.
Есть 2 viewController: А и В, мы используем navigationController для навигации между ними. У нас сначало был открыт А, в нем мы нажали что-либо и открылся В. Тоесть стек навигации: А->B.
Приходит сообщение low memory warning, при этом у A вызывается viewDidUnload, но только у А, потому что он не на экране и его объекты интерфейса можно освободить (у того контроллера, который находится на экране
viewDidUnload не вызывается, иначе юзер получит пустую форму). Дальше юзер поработал в В и нажал кнопку назад чтобы вернуться в A, при этом в A будет повторно вызван viewDidLoad чтобы восстановить объекты интерфейса и тд освобожденные в viewDidUnload.
У B, при возвращении к А, вызовется только dealloc (не в коеv случае не viewDidUnload)

[TRIMER]

Такое есть:

[NSNull null];

Пример использования:

NSArray *arr1=[NSArray arrayWithObject:nil]; //исключение 
NSArray *arr2=[NSArray arrayWithObject:[NSNull null]]; //без ошибок

[bobermaniac]

Но проблема [(NSObject *)nil retain] остается.

[TRIMER]

А какая проблема? Мб просто я не понял о чем вы. nil можно ретайнить и релизить сколько угодно, никаких ошибок и утечек не будет.

[bobermaniac]

Допустим, у меня есть массив, который я получаю в функцию и дальше считаю количество элементов. В случае, если мне в функцию передадут nil и я забуду сделать проверку — у меня будет каждый раз отрабатывать так, как будто мне передали массив из 0 элементов.

[TRIMER]

В Objective-C это нормально. Как я говорил выше на этом строится много логики. В принципе, достаточно логично: массив = nil -> в нем просто 0 элементов

[bobermaniac]

Это у вас на этом строится много логики. Вы же не думаете, что ваш подход — самый правильный и стройный?

Кроме того, nil и масссив из 0 элементов это разные вещи. Например, массив из 0 элементов вернет respondToSelector:@selector(objectAtIndex:) YES, а nil вернет NO.

[TRIMER]

Не только у меня. В том числе и примеры apple. Это стиль Objective-C.

[bobermaniac]

Радости от этого никакой, честно говоря.

[TRIMER]

Может я не правильно выразился. Я имел в виду следующее, в многих случаях это очень удобно, например, зачем писать так (как сделали бы по привычке, люди писавшие, на том же C):

-(void)dealloc
{
	if(obj1!=nil)
		[obj1 release];
	if(obj2!=nil)
		[obj2 release];
	[super dealloc];
}

Если проще использовать следующее (это вы увидите везде, и в примерах apple, и в принципе в примерах по Objective-C)

-(void)dealloc
{
	[obj1 release]; //если obj1==nil, то ничего не произойдет
	[obj2 release]; //если obj1==nil, то ничего не произойдет
	[super dealloc];
}

[bobermaniac]

Плохо то, что такое поведение навязывается.

[sha1dy]

Эх, живой явный последователь smalltalk

[diamant]

Именованные параметры в методах мне даже нравятся (хотя я плевался, когда впервые столкнулся с ними в ABAP :).
Категории напоминают JavaScript.
Но вот счётчики ссылок для меня пока за гранью добра и зла :(

[TRIMER]

Мне наоборот нравятся счетчики ссылок)) В последних версия Xcode есть компилятор со сборщиком мусора, так что если вас пугают счетчики ссылок, то просто используйте его (apple сам его рекомендует, по крайней мере для начала)

[rule]

сборщик мусора существует уже очень давно, а точнее с версии Мака 10.5, а если вы имеете ввиду ARC, то это не сборщик мусора, а статический умный «подставлятель» release/retain ов. Что просто декорирует а не убирает это поведение. Для iOS сборщика мусора не будет скорее всего, и я склонен к мысли что это хорошо, а не плохо. Да и компилятор к икскоду имеет не совсем прямое отношение и поддержка ARC появилась в LLVM3 достаточно давно, помоему более чем пол года назад.

[diamant]

Для iOS сборщика мусора, вроде бы, нет.
И Эплл, похоже, опять передумал, и рекомендует всем переходить с GC на ARC.

[TRIMER]

Да, я ошибся. Я имел в виду, конечно же, ARC. Просто сам использую ручное управление

[egormerkushev]

Счетчик ссылок — это как в поговорке «Сила есть – ума не надо», только наоборот.

[NeoCode]

С удовольствием прочитал бы продолжение. Про подсчет ссылок, сборку мусора, свойства, рефлексию и т.д. И еще — про внутреннее устройство системы диспетчеризации сообщений.

[Flanker_4]

Маленькое замечания по селекторам
Селектор это не совсем так

addFeature:withValue:asOptional:

Это скорей так

addFeature:::

Т.е. withValue и asOptional это Необязательные подсказки и их можно не указывать, вызвав метод так

[self addFeature :@"Foo" :@"bar" :YES]

или

SEL selector = @selector(addFeature:::)

[bobermaniac]

Правильно ли я понимаю, что

-(void) someMethod:(int)param with:(int)param2;

и

-(void) someMethod:(int)param inCaseOf:(int)param2;

неразличимы?

[egormerkushev]

А вот это вопрос!

[PapaBubaDiop]

Различимы до предупреждения компилятором и падения исполнением

[izen]

Вы полностью ошибаетесь, значимы все элементы селектора.

[Flanker_4]

Извините, я действительно был некомпетентен в этом вопросе.

[GreyWind]

Чушь. Неправильно.

[Limosha]

Не стоит начинать название метода с «get»:
-(Feature*) getFeature:(NSString*)name;

Хотя это и не обязательно, но Apple рекомендует это тут

Use “get” only for methods that return objects and values indirectly. You should use this form for methods only when multiple items need to be returned.

- (void)getLineDash:(float *)pattern count:(int *)count phase:(float *)phase;

[hashmap]

У меня это не совсем accessor, но спасибо, учту

[Krovosos]

Напишите еще.

[dukei]

А современный компилятор Objective C для иос поддерживает C++? Если да, то на каком уровне? Можно ли писать только на с++, вообще не используя синтаксис Objective C? А то этот язык уж очень опасен своей работой с памятью, кучей с сложностей с подсчетом ссылок, в то время как на с++ с его деструктуроми и перегрузкой операторов подсчет ссылок делается практически прозрачным и автоматическим.

[izen]

Objective-C гораздо проше чем C++. Писать использую C++ можно, но для работы с какими то системными либами (GUI, FS, etc) придется юзать Objective-C

[ivanzoid]

В Xcode ≥ 4.2 в коробке идёт Clang 3.0, соответственно его фичи смотрите здесь: clang.llvm.org/cxx_status.html. Только замечу, что C++11 доступен только в iOS ≥ 5.0.

Можно ли писать только на с++, вообще не используя синтаксис Objective C
Можно. Хотя, конечно бОльшая часть API в iOS — на Objective-C (оставшаяся часть — на чиcтом C), и использовать его всё равно придется.

А то этот язык уж очень опасен своей работой с памятью, кучей с сложностей с подсчетом ссылок, в то время как на с++ с его деструктуроми и перегрузкой операторов подсчет ссылок делается практически прозрачным и автоматическим.
Это вы зря. Мне после C++ было наоборот намного приятней работать с Objective-C. А после недавнего введения ARC (Automatic Reference Counting) вообще просто сказка.

[ivanzoid]

Правильная ссылка: clang.llvm.org/cxx_status.html

[dukei]

Ну, у меня нет опыта с Objective C. Я просто как то на синтаксис взглянул и ужаснулся, что там будет твориться, если случился Exception. Это ж в каждой функции надо блок finally писать. Код по сравнению с с++ получается просто нечитаемым. Впрочем, может это впечатление у меня с непривычки. Но пока я бы предпочел первым делом сделать с++ обертки для всех системных библиотек и забыть про эту нахлобучку на с.

[izen]

Exception в Objective-C(без GC) практически не применяються, только для каких то критических событий после который программа уже не может продолжать свое выполнение.
А код на Objective-C на порядок читабельнее кода на большинстве других языков, особеннос по сравнению с С++ :)

[dukei]

Наверное, потому и не используются, что они там прилеплены для галочки. Он вообще весь какой то внутренне противоречивый, на мой взгляд. Я не верю, что код, который делает одно и то же на с++ будет выглядеть сложнее, просто потому, что у с++ возможностей больше, хотя бы деструкторы. На Objective C читабельнее могут быть только очень простые программки. Чуть только что посложнее, и всё, жопа, память потеряна, обработка ошибок из миллиона строк.

Повторяю, это всё имхо, впечатление возникло от первого знакомства с синтаксисом.

[izen]

Ну так в этом и проблема, познакомтись с ним поближе и все пройдет) А код на С++ будет выглядеть сложнее как раз таки потому что в С++ больше возможностей. Весь Objective-C описыватеся очень небольшим набором концепций, в то время как в С++ разных тонкостей гораздо больше. А если говорить про имхо, то лично для меня С++ выглядит как уродливый набор разного рода фич который делали с мотивацией вида: «А не добавить ли на фичу <названиефичи>», а не затем что она действительно нужна. Помоему один из отцов основателей нашей индустрии говорил, что формальная граматика хорошого языка должна занимать не больше пары страниц, Objective-C думаю сможет уложиться в пару страница, а С++ точно нет :)

[dukei]

Может быть. :) Я просто хорошо знаю с++ и он мне кажется очень логичным и целостным, а Objective C нет, и первое знакомство повергло меня в ужас. А у вас обратная ситуация. Может, я не успел ухватить общую картину. Будем надеяться.

[izen]

Да он вам понравиться, я знаю двух С++ разработчиков которые по началу тоже плевались на Objective-C, а сейчас уже во всю на не нём под iOS пишут, причем вполне успешно.

[dukei]

Надеюсь. Слава Джобсу, переход на Objective C облегчен поддержкой с++. То есть использовать именно Objective C можно именно там, где это действительно удобно. Такие случаи, конечно, есть.

[izen]

Если вы планируете, что в будушем ваш проект будут поддерживать другие люди, то я крайне не рекомендую использовать С++ в нем, если это конечно не игра с каким то кросплатформенным движком. Это позволит вам избежать проклятий в свою сторону от будуших разрабов, так как поддержка кода на смеси Objective-C и C++ то еше удовольствие :)

[Agent_Smith]

Это уж точно, Objective-C++ та еще жесть.
Главное прочесть внимательно гайды и примеры от Apple, проникнуться идеологией Objective-C и apple coding convention. Тогда и код будет получатся красивый и кочественный, и отвращение к синтаксису очень быстро перерастет в симпатию.

[PapaBubaDiop]

Все языки одинаковы. API и project environment разные. И не пугайтесь Вы alloc release. В С никто не забывает malloc free, а если и забудет — никто не умрет.

[GreyWind]

Для говнокодеров, если руки из жопы — то уже ничего не поможет, кроме gc.

[TRIMER]

Вы забываете, что это не компьютер и общее количество памяти, а так же память на одну программу в iOS сильно ограничена. Поэтому «а если и забудет — никто не умрет» тут не подходит. Да, мелкие утечки я согласен, в принципе не страшно. А если вы забыли удалить какой-либо крупный объект? С учетом того, что приложения обычно юзеры не закрывают, а просто сворачивают и они так и висят месяцами. Рано или позно юзер развернет приложение и получит креш, если мы забыли удалить что-то крупное.

[egormerkushev]

Вы всё-таки перегнули палку на счет «месяцев». Обычно висит в памяти 3-4 приложения. Запускаете что-то крупное, какой-нибудь Infinity Blade — и всё, все отправляются в «terminate».

[TRIMER]

У меня и их знакомых висят штук 20. Никто terminate не получает, а предупреждения по логам сыплются

[izen]

Почему это он креш получит? если програма висит месяцами, то она там неисполняется, а просто висит.

[TRIMER]

Прочитайте внимательнее «юзер развернет приложение » (и в этот момент в очередной раз будет выделяться память на что-то здоровое).

[Vladek]

Да уж, у Objective C растёт не только популярность, но и возраст — скоро 30 лет ему исполнится. Неужели платформы Apple нативно не поддерживают более современные языки?

[dukei]

Может, потому, что Apple всегда особенная, и по особенному смотрит на вещи? :)

[izen]

Эм, а подскажите мне язык, сочитаюший в себе высокую скорость выполнения, динамизм и простоту уровня Objective-C?)

[dukei]

С++?

[izen]

простоту? серьезно? по вашему С++ простой язык? И в любом коде на С++ легко разобраться? Тем более С++ не очень хорошо подходит для GUI фреймворков.

[izen]

та и с динамизмом у С++ не очень.

[dukei]

Я не буду об этом спорить, соглашусь только, что Objective C выглядит (и, похоже, является) компромиссом. В результате при напмсании программ на нем, даже в случае хорошего фреймворка, надо быть чрезвычайно аккуратным, потому что компилятор ни хрена не проверяет и многие конструкции языка плохо взаимодействуют друг с другом.

В с++ все гораздо лучше. Там можно написать фреймворк, которым легко и безопасно пользоваться. В том числе и гуевый.

[dukei]

Другое дело, что такого фреймворка, может и не написано, но это как раз вина Apple.

[int_0x80]

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

я не фанат объектно-ориентированной идеологии разработки (мне ближе категории которыми оперирует процессор а не «очеловеченные» абстракции), но что касается реализации ООП в С++ — то это, тот еще костыль. Почитайте про смалталк хотя бы.

[dukei]

Не будем разводить холивар, я действительно очень поверхностно знаком с objective c.

Понятно, что и с++ и objective c оба являются надстройкой над с. Только при этом, на мой взгляд, с++ в этом отношении более качественный. Потому что мне ближе именно Ооп подход, и возможность сосредоточения на реальной задаче, а не на борьбе со счетчиками ссылок. В с++ есть деструкторы, в Java хоть сборщик мусора, а в objective c всё вручную. Не знаю, как вам, а мне эта рутина претит. Особенно учитывая, что в других языках с этим всё в порядке.

То есть, проблема даже не в синтаксисе аля смолтолк, а в том, что привнесенные объекты в обжектив с не образуют полную инфраструктуру, как объекты в с++

[int_0x80]

Вы не разобрались и делаете поспешные выводы, на основе слухов и домыслов.
В objectivec используется GC (например, в маке).

Что касатеся ифона, там собрщик мусора — гусенечный привод для телеги, поэтому в первых версиях ввели ручное управления счетчиками.
Но сейчас с появлением ARC (полгода как уже), об этом можно забыть и писать как для больших платформ, все будет учтено автоматом.
В результате стало проще писать и производительность кода осталось на высоком уровне… да и утечек теперь будет меньше ибо все учитывае автомат.

[dukei]

ну если так, то уже легче жить. Спасибо за надежду. Может, и подружимся с Objective C.

[Agent_Smith]

Чем dealloc не деструктор? Какие проблемы с памятью, вы о чем? Я перешел на Obj-C с .Net, да, первое время было тяжко и не превычно без GC. Но если придерживаться пары простых правил, то никаких утечек борьбы со счетчиками ссылок и в помине нет. К тому же в XCode встроен отличный статический анализатор, который большинство тривиальных утечек памяти легко детектит.

[hashmap]

Можно уточнить — какие, например? Для большинства и Lisp все еще язык из будущего.

[Vladek]

Любые популярные на данный момент у разработчиков и активно развиваемые. При этом популярность Objective C несколько искусственна, ибо программисты вынужденно начинают писать на нём, так как видят в платформах Apple золотую жилу.

Может после смерти Джобса, Apple повернётся лицом к разработчикам.

[int_0x80]

Не лезете в чужой моностырь, со своими уставами.
ObjectiveC — это основной столб мак платформы. На его базе построенно все семейство OS X и все программы под мак написаны на нем с использованием апловских фреймворков.

Не удивительно, что его (язык и фреймворки) перенесли на ифон, как перенесли и наработки из OS X в iOS.
Тоесть разработчику под мак, что бы начать писать под ифон, необходим самый минимум телодвижений.

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

[int_0x80]

моностырь — это такой фреймворк, по типу монотач :D

P.S. очень плохо, что нельзя редактировать свои коменты…

[zenden2k]

Я шокируюсь при одном только виде синтаксиса Objective-C. Чтобы настолько изуродовать старый добрый Си надо было постараться.

[dukei]

Хорошо, что я не один такой. А то я был в таком шоке, что вообще засомневался, как можно на таком кошмаре написать неплохую иос. Objective C выглядит как сиюминутная заплатка, которую в своё время неосторожно ввели, а потом просто не оставалось сил от неё избавиться. Вот все до сих пор и мучаются. Хорошо хоть с++ все таки поддерживается.

[int_0x80]

Я тоже шокировался синтаксису С после паскаля, в лихих 90-ых.
Но ничего, мне это не помешало статить системным программистом.

[hashmap]

Постараюсь в следующей статье переубедить.

[NeoCode]

Синтаксис не такой уж ужасный, просто непривычный. Зато сами возможности языка просто потрясающие. Чего только стоит отправка сообщений вместо вызова методов!

[Agent_Smith]

Синтаксис только кажется страшным, на самом деле, если не городить монтруозных вложенных конструкций, он очень легко читается. XCode отличная IDE, она прекрассно дописывает код, и сама расставляет скобочки там где это нужно. Просто не превычно по началу, но потом привыкаешь, и все становится намного лучше.

[hashmap]

Вижу надо продолжать. Почитал комментарии, пока план такой: философия языка (С, минимализм и вера в человека), id и его отличия от void* и Object, подсчет ссылок (почему это просто и что не так alloc/new )

[mOlind]

Рекомендую практикующим Obj-C программистам к ознакомлению: BlocksKit. И стиль написания и возможности из коробки помогают писать интересные вещи, для которых раньше требовались обходные пути. Например заменить делегаты блоками и не писать в UIAlertViewDelegate определение, какая же это мессага закрылась сейчас.

[vassabi]

возможно, вы сможете написать об этом статью? Чтобы таким новичкам, как я, легче было проникнуться ;)

[Agent_Smith]

Откройте документацию на сайте, там достаточно примеров к большинству методов.

[vassabi]

если вы об этом, то всё-же хорошая статья с примером «документации на сайте» не помешает :)

[travmik]

Хорошая статья. Сам джавист и тоже в свободное время начал почитывать про objC. Многое непривычно, но этого и стоило ожидать. У меня например есть коллега, который с java на хаскель перешел. И ниче — доволен))

[Throwable]

Вы будете удивлены, но большинство полезных концепций реализовано в Java в том или ином виде.

> Посылаем, а не вызываем, сообщения, а не методы

В Java есть класс Proxy, позволяющий генерить обертки для объектов. Кроме того, концепция давно знакома любителям AOP и Spring. Посылка же сообщений чаще всего предполагает именно асинхронный обмен данными, что в Java достигается помощи популярной ныне модели Actors. В данном же случае эта операция имеет свойства именно вызова функции (один тред, стек, блокирующий вызов). Так что можно сильно спорить по поводу корректности терминологии.

> Серьезный шок: любой может испортить мой класс, а не только я

Производные от Java языки типа Groovy, Xtend, Kotlin имеют похожую концепцию расширений (class-extensions). Причем сам класс никак не «портится», это только алиас функции, которая работает над классом в текущем namespace.

> Совсем шокирующее: неинициализированные ссылки не портят почти ничего

Оч. и оч. спорное «улучшение». Это нормально для «скриптовых» языков с нестрогим контролем типов, типа Groovy. В производных языках (Scala, Kotlin, Fantom) взяли концепцию nullable types от C#. Автоматический контроль null програмистам Java должен быть знаком от J2EE/EL и JavaFX Script.

Вот что действительно шокирует, так это синтаксис Objective-C, непохожий ни на один из привычных языков. Но это дело привычки.

[travmik]

> Автоматический контроль null

А можно подробнее?