Ответ на »сообщение 2681« (Руслан Богатырев)
___________________________

Скажите, из этого следует, что явное объявление типа в языках со статической типизацией -- это ненужная, второстепенная вещь?

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

Ответ на »сообщение 2676« (panda)
___________________________

За несколько лет у более чем десятка человек никогда не возникало потребности постоянно видеть, из какого модуля взят тип или функция. Ни при чтении, ни при отладке.

И Вы считаете такой аргумент убедительным? Т.е. если где-то когда-то кому-то не понадобилось -- то и не нужно? Мне известно немало проектов, реализованных на Бейсике. Людям тан не было нужды указывать типы переменных. Скажите, из этого следует, что явное объявление типа в языках со статической типизацией -- это ненужная, второстепенная вещь?

Ответ на »сообщение 2676« (panda)
___________________________

Ответ на »сообщение 2674« (Руслан Богатырев)
___________________________
В данном случае я говорил о коллективно разрабатываемом проекте довольно крупного размера. За несколько лет у более чем десятка человек никогда не возникало потребности постоянно видеть, из какого модуля взят тип или функция. Ни при чтении, ни при отладке.

Я тоже писал шесть лет на Дельфе - и "никогда не возникало потребности". После работы на Обероне и возвращении к Дельфе - возникает, потому что уже есть, с чем сравнивать. И уже неквалифицированный импорт кажется дикостью :-)

Ответ на »сообщение 2675« (Сергей Перовский)
___________________________

Если происхождение какого либо идентификатора вызывает сомнения, достаточно навести на него мышку и вместо ТABCClass можно увидеть uABC.TABCClass.

Замечательно, когда для программиста разницы между языком программирования и "костылями" инструментальной среды (IDE) практически нет. Она за него давно доделывает (додумывает) то, что должен делать он. Хорошо, я понял, сколь силен стереотип такого мышления в среде Delphi-программистов. Попробуем порассуждать.

Сильно напрягает? Много буковок? Введите синонимизацию в списке импорта (что сделал и Илья).
Вас смущают лишние буковки, когда смотрите на исходник в IDE? Какие проблемы: введите режим включения/отключения квалификации. Тогда IDE будет не додумывать, а строго выполнять команду. Тогда появится вопрос: а зачем напрягать мозги и пальчики программисту, чтобы явно вводить квалификацию?  Ответ: надо думать об отчуждении (пространство, время, персона), когда "костылей" с их настройками (и додумыванием) не будет.

Кто-то написал некий модуль и переслал его коллеге (наш случай с Geniepro). Коллега может не иметь всех тех настроек среды (и той же среды), ему нужен аккуратно отчужденный исходник (со всеми буковками) в текстовом виде (особенно, ежели в дороге, что может быть и равносильно случаю, когда кто-то обращается к исходнику спустя, скажем, лет 5).

Скажите, зачем Бейсик-программисту заморачиваться с типами данных, когда компилятор/интерпретатор додумает за него? Ведь и так работает, чего напрягаться-то? Зачем явно преобразовывать/приводить типы? Присвоил и ладно. Компилятор поймет, не осудит.

Додумывание и разрешение конфликтов среде и компилятору не надо никогда оставлять, если сам исполнитель может сказать -- так и никак иначе. Возможно, это будет несколько сильным сравнением, но неквалифицирующий импорт сродни include-директивам (со спасательным кругом в лице IDE). Непонимание идет от простого -- синтез превалирует над анализом, работа в качестве программиста-хозяина (по Ершову) над работой как программиста-слуги. Работа одиночки над работой в распределенном коллективе, когда постоянно из-за сроков надо смотреть/править чужие исходники "подмастерьев".

Отчуждение модуля (даже во времени) выглядит для многих дикостью. Видимо, отсюда и непонимание.

Ответ на »сообщение 2668« (panda)
___________________________

Ответ на »сообщение 2655« (AVC)
___________________________
Вопрос стоит именно в том, что лично мне абсолютно все равно, где размещается TThread: в Classes, SysUtils или еще где-то. Он все равно будет очень быстро найден и скопирован.
Мне же утверждали, что легко я его смогу скопировать только если в моем модуле будет явно написано Classes.TThread. А если просто TThread - то мне будет намного сложнее найти реализацию.
Знаете, реализация интересующей функциональности может быть рассредоточена по десятку-другому модулей, откуда ее надо аккуратно "отсечь" и перенести... Вот вам и "найти реализацию по щелчку мышки"... :-)

Ответ на »сообщение 2644« (Geniepro)
___________________________
Ну в хаскеле это небольшая проблема.
А вот на турбо-паскале я когда-то написал процедуру move, а потом долго не мог понять почему компьютер перезагружается. ;-)

Ответ на »сообщение 2674« (Руслан Богатырев)
___________________________

Я разве утверждал, что она возникает лично у Вас? Вы писатель и читатель в одном лице, если я правильно понимаю. В противном случае надо спрашивать не Ваше мнение, а мнение тех людей, которые разбираются с Вашим исходным текстом и при том знают, что есть такая возможность, как квалифицирующий импорт.
В данном случае я говорил о коллективно разрабатываемом проекте довольно крупного размера. За несколько лет у более чем десятка человек никогда не возникало потребности постоянно видеть, из какого модуля взят тип или функция. Ни при чтении, ни при отладке.

Ответ на »сообщение 2674« (Руслан Богатырев)
___________________________
>>>Это не просто наглядность документации, а гарантия многих ошибок
Гарантировать ошибки это конечно здорово :)
Меня чтение таких конструкций, как Classes.class сильно утомляет. Простие за албанский "ниасилил, слишком много буквов".
Если происхождение какого либо идентификатора вызывает сомнения, достаточно навести на него мышку и вместо ТABCClass можно увидеть uABC.TABCClass.
Когда выражения перестают помещаться на строчку из за слишком длинных имен, ясности это не добавляет.
Скорее всего речь опять идет о разнице парадигм. При возможности динамически обратится в любой момент к любому модулю, могут возникать проблемы с однозначностью квалификации при редактировании кода. Вопрос упирается в отчуждение модулей. И понятно, что для программистов на Дельфи обязательность квалификации выглядит дико. 

Ответ на »сообщение 2673« (panda)
___________________________

Видите ли в чем дело... У меня просто нет проблемы локализации. "Find Declaration" работает, отладка всех модулей (при необходимости и VCL) - тоже. Мне не надо видеть в моем модуле, откуда я импортировал тип или функцию.

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

Для меня принудительно квалифицирующий импорт вещь давно очевидная (отказался в Модуле-2 от неквалифицирующего импорта еще до выхода Оберона в публичное плавание), поэтому даже никогда и не поднимал этот мелкий (в моем понимании вопрос). Но когда стал читать исходники Geniepro, понял, что локализовать что откуда -- не могу. Думаю, несложно эту ситуацию спроецировать и на Delphi. Случай, когда писатель#читатель. Это не просто наглядность документации, а гарантия многих ошибок (не только конфликта имен -- это мелочь).

Пример со словарем, похоже, Вас мало убедил. Странно, да ладно. Просто по долгу службы вынужден ковыряться в таком объеме недостоверной информации, что по привычке для меня является само собой разумеющимся то, что есть в программировании понятие достоверности (надежности) модулей. Мы как-то этот вопрос уже детально обсуждали в ветке по Оберону в плане маркировки проверенных и одобренных модулей (trusted), а также иерархического импорта SYSTEM-зависящих модулей. Для Вас, как я понимаю, любой модуль вне зависимости от сырости (текущего состояния проекта) и подготовки внешними, территориально удаленными участниками команды, является надежным (достоверным). Для меня -- нет.

Ответ на »сообщение 2669« (Руслан Богатырев)
___________________________

Это во многом решает задачу локализации. В этом плане проблемы, связанные с локализацией/достоверностью (при работе сторонних подрядчиков, непроверенных, системно-зависимых и т.д. и т.п. модулей), в Обероне решаются проще.
Видите ли в чем дело... У меня просто нет проблемы локализации. "Find Declaration" работает, отладка всех модулей (при необходимости и VCL) - тоже. Мне не надо видеть в моем модуле, откуда я импортировал тип или функцию.