objective-c

[Alex_3112]

Ты слышал о duck-typing? Он неплохо справляется с задачей. Если тебе надо записать объект в базу, то тебе нужно пара методов: save и validate. И не надо все остальное (ну например). В статическом языке, чтобы добится этого тебе нужно иметь четко выделеный интерфейс с этими методами, как отдельную сущность, например Storable. А в куске кода, который читает объект из строки и записывает его в базу, нужен еще метод: load_from_string. Со Storable этот кусок уже работать не может и ему либо надо кросскастать, либо работать с более конкретными классами.

Определяем StorableAbstractClass где load_from_string() выбрасывает exception. И вместо Storable работаем с Abstract Class.

Приведу еще одну метафору.
Мне удобно, когда ручка лежит не в верхнем ящике стола, а прямо на столе. Не нужно открывать ящик и искать там ручку.
Мне удобно, когда папка с документами лежит не в нижнем ящике стола, а прямо на столе. Не нужно нагибаться, открывать ящик и доставать оттуда папку.
Мне удобно, когда книга, которая мне нужна, не стоит на полке, а лежит прямо на столе. Не нужно вставать со стула, идти к шкафу, брать книгу и идти обратно.
За день мне может понадобиться много папок и книг.
К концу для я могу понять, почему книги все-таки обычно стоят на полке, а папки лежат в ящике стола.
Если я не пойму этого сегодня, то на следующий день это случится точно.

[реднек]

Мы об этом ведь уже говорили.
Но там ещё одна очень смешная вещь есть - "очень правильная объектно-ориентированная программа" со всей своей очень строгой типизацией довольно часто компилируется в просто неработающий код. ( там все эти наследования и конструкторы перепутаются так - что исполняемый код сведётся к единственной команде ret в лучшем случае ).
От таких вещей никакая строгая типизация не защищает вообще.

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

[реднек]

Определяем StorableAbstractClass где load_from_string() выбрасывает exception. И вместо Storable работаем с Abstract Class.

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

[Alex_3112]

По-моему опыту - у клиента практически не бывает "кривого браузера". Клиент только кеш забывает очищать. А в самом языке Java именно глюки наблюдались при переходе от одной версии к другой ( swing и awt чуть по-разному работали после перехода с 1.3 на следующую.

Это GUI, тут всего можно ожидать. А вот разница между браузерами, и даже версиями браузера может гораздо чувствительнее отражаться на JavaScript. У меня была куча примеров.

[crazy-mike]

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

Эти ошибки несоответствия типов вообще не вылавливают собственно проблемы. В конце-концов (C++ по-варварски ) можно операцию + переопределить с параметрами void& , void& и никакой компилятор для неё не будет выдавать никаких предупреждений.

[crazy-mike]

Это GUI, тут всего можно ожидать. А вот разница между браузерами, и даже версиями браузера может гораздо чувствительнее отражаться на JavaScript. У меня была куча примеров.

Как только отказались от IE у клиентов - все проблемы практически исчезли. Для всего остального просто есть "общее подмножество JavaScript+DOM" ( отличается только Drag-and-Drop в Firefox. ).

[Alex_3112]

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

Пардон, но если мы признаем наличие ситуации, что объект может не поддерживать какую-то функцию, мы должны справляться с этой ситуацией в runtime. Непринципиально, ловим мы exceptions или пишем if-else. Важно, что если просходит ошибка, мы всегда знаем, какой исходный файл открыть и увидеть, откуда эта ошибка взялась.

[Alex_3112]

Как только отказались от IE у клиентов - все проблемы практически исчезли.

Эх, не все могут позволить себе такую роскошь

[реднек]

Эти ошибки несоответствия типов вообще не вылавливают собственно проблемы. В конце-концов (C++ по-варварски ) можно операцию + переопределить с параметрами void& , void& и никакой компилятор для неё не будет выдавать никаких предупреждений.

Правда чтоль? Помнится плюсы более "строги".

[реднек]

Пардон, но если мы признаем наличие ситуации, что объект может не поддерживать какую-то функцию, мы должны справляться с этой ситуацией в runtime. Непринципиально, ловим мы exceptions или пишем if-else. Важно, что если просходит ошибка, мы всегда знаем, какой исходный файл открыть и увидеть, откуда эта ошибка взялась.

Ну так и в динамическом - то же самое, открываешь файл и смотришь где ошибка взялась. Или ловишь экцепшн и смотришь его стэктрейс. И тела функций еще можно посмотреть, а не только имена.