runewalsh писал(а):Паскаль не может рулить на «больших проектах», потому что в Паскале ПРИНЯТО...
Или вот, по крайней мере, в среде Delphi ... есть ТРАДИЦИЯ слишком привязываться к платформе...
...FreeAndNil, официально НЕ ПРОВЕРЯЮЩИЙ тип параметра — это вообще вышка (пропускает незамеченной смену типа FreeAndNil'ящейся переменной с объекта на интерфейс, массив или запись — что там про типизацию?).
Ну это же к Паскалю, как к языку, не относится, это вопрос требования к написанному коду, внутри одного проекта/команды.
а так, это всё особенности бизнес модели Делфи
runewalsh писал(а):Вспомните, например, зачем были введены интерфейсы
Интерфейсы были введены, как некий внешний стандарт.
Их вполне можно было не вводить, а говорить разработчикам, вот давай тебе обращаться к интерфейсам, через record-ы, и ручками вызывайте AddRef, Release, где вам угодно. (как это происходит в Си++)
Но концепеция managed-типов победила
В том же FPC уже давно присутствуют нерабочий cppclass. И ничего
может и допилят когда-нибудь, и можно будет какой-нить Qt без лишних обёрток использовать.
runewalsh писал(а):..., или как объяснялись изменения в компиляторе под iOS.
Та же песня - внешний стандарт. (я кстати не знаю, что именно в Делфи менялось, но что менялось в FPC, я лично держу руку на пульсе).
Можно общаться с Objective-C, не с помощью синтаксиса компилятора, а через run-time функции.
НО при этом кода будет написано в разы больше (я сам писал такие обёртки). Что ещё хуже, при написании такой обёртки можно легко ошибиться а потом долго и упорно искать ошибку.
Но вот, что через ран-тайм не сделать, так это не добавить описание используемых ObjC классов. И их придётся подгружать уже динамически (вместо того, чтобы это сделал системный загрузчик).
Можно конечно, ещё делать всякие asm вставки в программу, которые бы добавляли такое описание в итоговый файл, но это уже сликшом
А так, компилятор берёт на себя, всю эту бюрократию.
Кстати, я хз, как в других языках (питон, перл, С#) идёт обращение к ObjC, но есть мнение, что через "мостики", писанные на Ся-х в форме удобных функций, которые в свою очередь присодеиняются к классам самого языка.
Проблема таких мостиков, в том, что при изменении интерфейся ObjC класса (или добавления нового), придётся сначала подправить мостик, а потом подправить обёртку, которая мостик использует, (и потом подправить код, который эту обёртку использует).
Т.к. в FPC, классы obj-c нативные, то правка происходит только два раза (правим/добавляем описание, правим/добавляем код), а не три.
я это всё к чему, что добавление нового синтаксиса в язык, с целью поддержать внешний стандарт (как то COM-интерфейсы, dispatch-методы, ObjC классы или cpp-классы), это вынужденная мера, но она хорошая, т.к. облегчает труд программиста, перекладывая труд по использование внешнего стандарта на компилятор.
А в FPC вообще ввели modeswitch, который позволяет (психологически) изолировать такие расширения от синтаксиса языка