Ответ на »сообщение 3714« (Trurl)
___________________________
А если это handle := open(name, mode) ?


А если это
h := o(n,m)

Утрировать конечно можно все. Вот только выбор названий для всех сущностей в программе является обязанностью программиста, и никакой импорт эту обязанность не отменял и не заменял.
В ООП можно позволить себе generic имена типа open, поскольку там это метод класса, который и идентифицирует операцию.
В ФП, называть функции такими именами в языках без обязательного квалификатора - ошибка программиста.
А вот в Эрланге - ради бога можно и file.open :))

Ответ на »сообщение 3710« (Илья Ермаков)
___________________________

Не знаю, нужно ли рассказывать, кто такой бывший главный архитектор Microsoft Чарльз Саймони (Charles Simonyi) и что есть венгерская нотация (Hungarian notation). Word, Excel и Windows создавались под его руководством.

В начале 1960-х гг. Саймони на своей родине в Венгрии писал программы для советского компьютера "Урал-2". Именно тогда, работая в машинных кодах, он и приобрел умение создавать максимально эффективные программы, функционировавшие в условиях крайне ограниченных машинных ресурсов. Привычка делать мнемонические обозначения вылилась у него в создание того стиля формирования идентификаторов, который теперь известен под названием "венгерская нотация". См., например, http://en.wikipedia.org/wiki/Hungarian_Notation

Во многих языках во избежание недопонимания (какому типу или модулю принадлежит сущность) в само имя зашивают "тег принадлежности". Для квалифицирующего импорта "зашитие" выливается в квалификацию (обязательную). Более того, максимальный эффект от этого IMHO был достигнут в языке Modula-3 -- где в случае использования модуля как контейнера одного АТД (абстрактного типа данных) использовался обычно лаконичный унифицированный идентификатор (T). Например, Stack.T, Set.T и т.д.

Ответ на »сообщение 3702« (Jack Of Shadows)
___________________________
Квалифицировать всегда только потому что в одном из ста случаев может случиться неявная подмена, это экстремизм, то есть доведение до крайнего случая. Любителей экстремизма всегда хватает, но большинство вас не поймут.
В одном из ста – это очень много. Реально бывает гораздо меньше. Тем не менее, разработчики и пользователи Эрланга – явные экстремисты. Может быть, именно поэтому их системы так надежны. ;-)
Потом, глядя на название функции
myFile := OpenFile("test.txt", ReadWrite)
вы не можете понять что же она делает.
А если это handle := open(name, mode) ?

Ответ на »сообщение 3711« (Geniepro)
___________________________
You beat me to it :)
Что интересно, Руслан думал, что типа щас сьязвит. :))
Вот она зашоренность. Некоторые вещи даже не оспариваются, воспринимаются как данность. В данном случае строгая типизация однозначно связывается с необходимостью явно указывать типы во всех случаях.
По другому ведь и быть не может. :))

Ответ на »сообщение 3709« (Руслан Богатырев)
___________________________
:))) Руслан, вы прекрасно кстати справились с описанием type inference? то есть автоматического выведения типов.
Вправда в первом пункте сделали ошибку. Но пункты 2 и 3 - правильные.
А пункт первый я вам щас подправлю:

O: Без объявления тип переменной непонятен.
Н: Чушь, тип переменной в подавляющем большинстве случаев однозначно проистекает от опереации над ней производимой.

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

Обязательное объявление типа переменной - Необязательное объявление типа переменной

O: Без объявления тип переменной непонятен.
O: Без объявления не знаешь, каков тип переменной
O: Без объявления непонятно, какой из двух (трех, десяти) типов для переменной используется.

H: Чушь. Автоматический вывод типов нам поможет! :о))


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

А это да, такое иногда бывает, когда среда разработки во время написания тела новой функции начинает париться и отказываться предлагать code-complition (в F# с таким столкнулся)... ;о)

Ответ на »сообщение 3708« (Jack Of Shadows)
___________________________
Если смотреть на схему именования, как она принята при неквалиф. импорте, то простое "дописывание" имени модуля может и правда делать код громоздким. Потому что само имя, к примеру, класса, уже включает в себя информацию о том, что он за птица...
Если язык с обязательной квалификацией, то семантика названия не дублируется именем модуля, а наоборот - делится на две части. Так же, как имя каталога и имя файла.

Пример - в ББ графика построена на схеме Model-View-Controller. Я пишу новый графический объект. У него будет View, Model и Controller. Я не буду называть эти типы MyEditorView, MyEditorModel и MyEditorController, как это было бы принято в Дельфи, например. Я их прямо так и назову - View, Model и Controller. Помещаю их в модуль MyEditor, к примеру.

Затем использую именование MyEditor.View, MyEditor.Model, MyEditor.Controller.
И в среде десятки других типов с точно такими же названиями. Название типа всего лишь определяет техническое назначение: "гайка", "шайба", "винт". А название модуля определяет тот компонент, к которому та или иная "гайка" относится. Чем плохо?

А вот дельфистов, которые восстают против полной квалификации, я на самом деле понимаю. Поскольку язык допускает и поощряет Н-схему, то любой разработчик компонента не может себе позволить именовать типы по вышеописанному принципу, он думает - а что, если имена совпадут? - и, естественно, дублирует имя компонента в названии класса: MyEditorView... Если учесть, что везде и всюду в существующем коде УЖЕ все названо по такому принципу, то потребовать от программистов писать MyEditor.MyEditorView - это громоздко и неудобно...
Дельфистов-то понять можно, но вот компанию Борланд, и компанию Микрософт, в Шарпе заботливо разложившую такие же "грабли" понять сложно...

Ответ на »сообщение 3708« (Jack Of Shadows)
___________________________

:)

Обязательное объявление типа переменной - Необязательное объявление типа переменной

O: Без объявления тип переменной непонятен.
Н: Чушь, смысл кода в применении сущностей, а не в том чья это переменная

O: Без объявления не знаешь, каков тип переменной
H: Чушь, вы не ищете тип КАЖДОЙ переменной, на которую смотрите. Для того они и созданы, чтобы вы не отвлекались на нижний уровень абстракции каждый раз. А в тех РЕДКИХ (по сравнению с чтением названия переменных) случаях, когда вам надо прочитать и тип переменной, прекрасно справляется "костыль" в виде IDE

O: Без объявления непонятно, какой из двух (трех, десяти) типов для переменной используется.
Н: Да, тут объявление нужно. И мы им пользуемся. Но таких случаев считанные проценты, по сравнению с ситуациями, когда тип без объявления определяется однозначно.

Ну а дальше выбор конкретного лагеря уж пусть каждый делает для себя сам.

P.S. Мои глубочайшие извинения за вынужденный плагиат.

Ответ на »сообщение 3707« (Руслан Богатырев)
___________________________
Обязательный квалификатор - Необязательный квалификатор

O: Без квалификатора код непонятен.
Н: Чушь, смысл кода в применении сущностей, а не в том откуда импортированы эти сущности

O: Без квалификатора не знаешь где искать код функции
H: Чушь, вы не читаете код КАЖДОЙ функции на которую смотрите. Для того они и созданы, чтобы вы не отвлекались на нижний уровень абстракции каждый раз. А в тех РЕДКИХ (по сравнению с чтением названия функции) случаях когда вам надо прочитать и код функции, с прыжком в ее тело прекрасно справляется "костыль" в виде IDE

O: Без квалификатора непонятно какая из двух (трех, десяти) функций вызывается.
Н: Да, тут квалификатор нужен. И мы им пользуемся. Но случаев функций с одинаковыми именами считанные проценты, по сравнению с функциями, чье имя определает их однозначно.

Ну а дальше выбор конкретного лагеря уж пусть каждый делает для себы сам.

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

Не слишком логично, IMHO, использовать строгий язык (Паскаль), а в местах межмодульных соединений от этой строгости вдруг отказываться и полагаться на "авось". :)

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

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