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

Скоропалительный вывод, D как раз по элегантности и простоте очень близок к си.

Что проще -- сделайте не скоропалительный, представьте публике свой анализ, сопоставив D с Си и C#. Интересно посмотреть, к какому из них он будет ближе.

Конечно лучше чтобы не было никакого доступа?
Кстати вместо просто точки можно использовать modulename.varname

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

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

По модулям, по сравнению C/C++ и даже шарпом/явой вполне хорошо.


Scope Operator -- отличное средство, чтобы наплодить ошибок (поставил перед идентификатором точку -- берется имя извне процедуры, не поставил -- берется внутреннее имя). Не разглядел точку -- твои проблемы.


Конечно лучше чтобы не было никакого доступа?
Кстати вместо просто точки можно использовать modulename.varname


В общем, поделка с претензией а-ля C#. Желание побольше вкусностей -- все тот же принцип сундука. Си на этом фоне куда как более элегантный язык. Его простота прибивает все эти "вкусности" с двусмысленными наворотами.

Скоропалительный вывод, D как раз по элегантности и простоте очень близок к си.

Ответ на »сообщение 4802« (Иван Горячев)
___________________________

Да, а введи они обязательный квалифицированный импорт - секция документации про модули в половину меньше бы стала.

Просто Модула-2 и Оберон прошли мимо них. Стороной.


Что касается scope operator - мне в Обероне иногда не хватает возможности обратиться к переменной в собственном модуле. Ну не в таком странном виде, но в традиционном module.var.

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

Что касается языка D, то это вообще говоря интересная тенденция: похоже программистов достала монстроподобность C++, Java, C#. Они решили сделать ревизию классики -- Си. Но наступили на те же грабли -- стали пичкать язык всякими вкусностями. Поправить библиотеки спустя "-дцать" лет можно, поправить среду -- тоже. Но если начинают язык превращать в зоопарк -- какую новую клетку/вольер соорудят под нового диковинного заморского зверя -- то языку кранты. Побалуются, поиграются и  вернутся к истокам -- Лиспу, Прологу, Форту, Си. К языкам-ядрам. Только будет это уже на новом витке эволюции. Когда вызреют подходы к программному производству, где главенствующая роль языка в реализации проекта уступит место другим вещам. А язык начнет в большей степени влиять на инженерное мышление, на способность человека адаптироваться к постоянно меняющемуся окружению и новым задачам. Случится это тогда, когда придет понимание, что в программировании сам язык как символика -- не главное. Равно, как и инструментальная среда. Во всем должен быть разумный баланс и чувство меры.

Если посмотреть на рейтинг-лист языков (TIOBE), то нетрудно заметить, что в первой двадцатке популярности следом за большой тройкой (Java, Cи, C++) компактно расположилась пятерка скриптовых языков (PHP, Perl, Python, JavaScript, Ruby). А язык D тем временем на крыльях летит к народной славе и вот-вот обойдет остывающую звезду -- Delphi. См. http://www.tiobe.com/tpci.htm

А вообще странно - как у них вот это There's only one instance of each module, and it is statically allocated сочетается с этим Cycles (circular dependencies) in the import declarations are allowed as long as not both of the modules contain static constructors or static destructors.
Мне всегда казалось, что должно быть или или. Судя по дальнейшей фразе Violation of this rule will result in a runtime exception модули у них существуют в динамической памяти, аки прочие объекты. Отсюда интересный вопрос - можно ли будет в рантайме модуль преобразовать в класс и наоборот?

Руслан Богатырев:
Да, а введи они обязательный квалифицированный импорт - секция документации про модули в половину меньше бы стала.

В принципе, если оставить только static import - то это будут более-менее полноценные модули. У которых все потроха наружу :) Вот такое решение, кстати, мне совершенно непонятно.

Что касается scope operator - мне в Обероне иногда не хватает возможности обратиться к переменной в собственном модуле. Ну не в таком странном виде, но в традиционном module.var.

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

У них, похоже, вообще нет экспорта на уровне модулей. Какие там интерфейсы модулей! Т.е. все, что есть в импортируемом модуле: бери -- не хочу.

Ответ на »сообщение 4796« (Димыч)
___________________________

Modules
    Many correctly argue that C++ doesn't really have modules. But C++ namespaces coupled with header files share many features with modules.

Все те же грабли. По умолчанию неквалифицирующий импорт (квалификация по желанию, либо когда грянет гром, либо использование static-импорта -- обязательного квалифицирующего). Коллизия имен. Плюс public-импорт (импорт в модуле C интерфейса B неявно является и импортом интерфейса A, который импортировал B -- и так цепочка неявного импорта может быть сколь угодно длинной и запутанной). При этом интерфейс называется модулем, а словом interface обозначается интерфейс класcа. Нет правила No Paranoia Rule (модули дают свои средства информационного сокрытия, но в них впихивают еще и классы). Прямая завязка имен модулей и пакетов на имена файлов -- нет на этом уровне имен чувствительности к регистру.

Если есть "public import" и "static import", то напрашивается возможность применения "public static import", а что это за будет зверь -- загадка.

Scope Operator -- отличное средство, чтобы наплодить ошибок (поставил перед идентификатором точку -- берется имя извне процедуры, не поставил -- берется внутреннее имя). Не разглядел точку -- твои проблемы.

В общем, поделка с претензией а-ля C#. Желание побольше вкусностей -- все тот же принцип сундука. Си на этом фоне куда как более элегантный язык. Его простота прибивает все эти "вкусности" с двусмысленными наворотами.

Ответ на »сообщение 4795« (Димыч)
___________________________

Ответ на »сообщение 4794« (Илья Ермаков)
___________________________
Илья, ссылка живая :)
Запятую в конце убери...
http://www.digitalmars.com/d/index.html

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

Порадовало, что ребята вводят синт. поддержку контрактности - аля Эйфель.
Но при этом прикололо, что не решаются выкинуть такой рудимент, как switch с бреками. =/==, конечно, оставили тоже.

Не является компонентным - подчеркнуто, что динамическая загрузка классов не поддерживается. (И, вероятно, какие-то особенности, введенные в язык, этому препятсвуют).
В целом, на мой взгляд, из Паскаль-семейства сопоставим с Адой - "заточенность" та же, тоже объемный язык, но вроде как довольно продуманный, также не дружит с компонентностью и по тем же причинам.
Единственное - в Ада все низкоуровневые средства изолированы донельзя, как в D с этим - я что-то не понял... Если так же, как в С, то это большая дыра.

Плюс бросилась в глаза пара-тройка синтетических вещей из ФП.

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


Вы, кажется, опять смешиваете понятия "модульность" и "компонентность"...

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

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

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

Ссылка мёртвая :(

Ссылка живая, только надо запятую в конце убрать:
http://www.digitalmars.com/d/index.html


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

Вы, кажется, опять смешиваете понятия "модульность" и "компонентность"...
То, что в Блекбоксе называется модулями, на самом деле является компонентами,  модули Модулы-2 - не такая уж и сложная концепция...

Кстати, модули в D могут содержать и свободные процедуры, так что не всё там завязано на классах, как в Яве.