Здравствуйте, D. Mon, Вы писали:

I>>Это сказки. vibe это как Node.js только на D и с меньшими возможностями.

DM>Ну да, там нет callback hell, нет проблем с многопоточностью, нет тормозов, нет откладывания тупых ошибок до рантайма, и еще много чего нет.

В node.js ничего это нет, кроме тупых ошибок до рантайма. Они бывают в основном у тех, кто и строчку кода без дебуггера не может написать.

Здравствуйте, D. Mon, Вы писали:

DM>И все! Тип возвращаемого результата генерящихся функций тут выводится автоматически. Генерятся они посредством шаблонов, никаких манипуляций со строками. И все это в пределах одного маленького модуля, который элементарно импортируется. Никаких заморочек с раздельными стадиями компиляции.
Интересно.
А как гарантируется вызов этого всего во время компиляции ?
template это ясно, а вот вызов функции и foreach ?

Если я добавлю побочный эффект:

foreach(funname; __traits(allMembers, Proxy))
{
  writefn("Hello"); 
  __traits(getMember, myProxy, funname) = &genCall!funname;
}

DM>Если не лень, можете показать, как такая задача решается в других статически типизированных языках, сравним.
В данном случае здесь выйдет тот же код, только другой API.

Макросы Nemerle могут больше, например перезаписывать тело методов.

F([NotNull] a : object) : void { ... }

Будет после раскрытия

F(a : object) : void { when(a == null) throw ArgumentNullException("a", "a is null"); ... }

DM>Не без этого. Те же AST-макросы там вечная тема, которую периодически упоминают, но не решаются даже начать проектировать, оставляя на гипотетическое будущее и версию 3.0.
Цитирование это очень мощная штука.
Кстати в Rust уже есть макросы.

Здравствуйте, DarkEld3r, Вы писали:

DE>Можно немного подробнее?

DE>Вообще, я не считаю это серьёзным недостатком, но один момент всё-таки смущает. Возможна ведь ситуация, когда есть две никак не пересекающиеся иерархии классов, причём без интерфейсов — просто линейное наследование. И в какой-то момент нам требуется создать наследника обеих иерархий. Так как они независимы, то никаких ужасов множественного наследования не будет. Но если в самом начале никто не позаботился об интерфейсах, то в С++ мы всё-таки можем отнаследоваться. В D (а так же С# и т.д.), насколько я понимаю, придётся всё-таки вводить интерфейсы. Так?

Да, безусловно. Я имел в виду, что интерфейсы в D несколько менее ограничены (ближе к классам), чем скажем в Java. Но всё же не настолько, как абстрактные классы в C++.

DE>Понятное дело, можно заявить про "кривой дизайн" и т.д. Но тем не менее, на С++ "проблема" решается, вернее её даже нет.

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

Здравствуйте, DarkEld3r, Вы писали:

DE>Ну да, но шутки типа этой

Автор: Qbit86
Дата: 19.02.14

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

О, а чем uniform initialization не нравится то? ) Как раз очень полезная фича, можно сказать восстанавливающая справедливость. А то раньше была удобная инициализация только для C массивов, а теперь и C++ массивам (vector, array) дали. Т.е. даже если не пользоваться данной фичей самому (не делать своих функций с подобными параметрами), то просто от использования её стандартной библиотекой уже явный позитив идёт. Причём он приводит как раз к упрощению и унификации.

Здравствуйте, DarkEld3r, Вы писали:

DE>Вообще, я не считаю это серьёзным недостатком, но один момент всё-таки смущает. Возможна ведь ситуация, когда есть две никак не пересекающиеся иерархии классов, причём без интерфейсов — просто линейное наследование. И в какой-то момент нам требуется создать наследника обеих иерархий. Так как они независимы, то никаких ужасов множественного наследования не будет. Но если в самом начале никто не позаботился об интерфейсах, то в С++ мы всё-таки можем отнаследоваться. В D (а так же С# и т.д.), насколько я понимаю, придётся всё-таки вводить интерфейсы. Так?
DE>Понятное дело, можно заявить про "кривой дизайн" и т.д. Но тем не менее, на С++ "проблема" решается, вернее её даже нет.

Именно эта конкретная проблема, то есть скрещивание двух независимых иерархий в D тоже легко решается Alias This

Здравствуйте, Ikemefula, Вы писали:

I>>>Это сказки. vibe это как Node.js только на D и с меньшими возможностями.
DM>>Ну да, там нет callback hell, нет проблем с многопоточностью, нет тормозов, нет откладывания тупых ошибок до рантайма, и еще много чего нет.
I>В node.js ничего это нет

Это сказки.

Здравствуйте, _NN_, Вы писали:

_NN>Интересно.
_NN>А как гарантируется вызов этого всего во время компиляции ?
_NN>template это ясно, а вот вызов функции и foreach ?

В данном примере идет заполнение полей структуры. Само заполнение конкретными значениями — указателями на функции происходит в рантайме, там и writeln и что угодно еще может быть. А генерация функций, на которые получаются указатели, происходит статически при компиляции.

Здравствуйте, _NN_, Вы писали:

_NN>А в чем проблема то ?
_NN>В Nemerle/Scala это работает

_NN>Каждый макрос добавляет метод и компилятор создает класс со всему нужными методами.

Ну так а если там будет где-то код вида "if(x) A.AddMember(...);", где x — это переменная (т.е. значение не известно на время компиляции), то какой набор методов будет у типа A в итоге?

Что-то я пока так и не понял как сделать подобные вещи во время компиляции. Вот в рантайме подобное естественно без проблем, но это вообще другое дело (и на мой взгляд никчемное).

Здравствуйте, Sinclair, Вы писали:

S>А можно сколь-нибудь убедительный пример?
Нет. (:
Единственное, что так сразу в голову приходит — это только пример с кодом, в который надо "побыстрее" изменения внести без масштавного рефакторинга и переделки архитектуры.

S>Для задач типа "давайте сделаем наш класс сериализуемым" поддержка в D есть, и значительно лучше, чем в С++.
Хотя, наверняка, можно что-то помимо сериализации придумать.

Здравствуйте, alex_public, Вы писали:

_>О, а чем uniform initialization не нравится то? )
Всем нравится, кроме того, что это "ещё один способ". Понятно, что без этого никак, потому и хочется в "более новых" языках находить меньше костылей.

Впрочем, один момент всё-таки не очень:

int i = {10}; // int
auto a1 = 10; // int
auto a2 = {10}; // initializer_list

Логично, но инициализация получается не такая и "uniform".

Здравствуйте, Artifact, Вы писали:

A>По-моему автору(авторам) языка D не хватает критики со стороны. Уж больно похоже, что разные вещи включены в язык непродуманно, а просто потому, что авторам захотелось. Это, опять же мой взгляд со стороны. D я, можно сказать, вижу впервый раз. Кстати, не понравился синтаксис, и дело тут не в похожести или непохожести на С/C++, а в недостаточной продуманности — опять же это моё впечатление только от просмотра исходников. Всё-таки, если взять С++, там есть коммитет, то есть порядочное число людей с разными мнениями. И они всё-таки делают свою работу: новые вещи, включаемые в язык, не вызывают когнетивного диссонанса, и вписываются в старый язык органично. D же выглядит как полигон для разных идей, а ни как серьёзный, продуманный до мелочей язык программирования. Опять же это моё мнение.

Хы, ну называть D идеальным я бы тоже не стал, но уж никак не при сравнение с C++. Особенно если вспомнить про основу современного C++ (шаблонную магию), а потом взглянуть на то, как подобное же реализовано в D.

А есть какие-то конкретные претензии к D для обсуждения или это просто некое интуитивное ощущение? )

Здравствуйте, FR, Вы писали:

FR>Именно эта конкретная проблема, то есть скрещивание двух независимых иерархий в D тоже легко решается Alias This
В принципе, да (реально забыл про эту возможность). Только, к сожалению, не "решается", а "решится когда-нибудь":

Note: Multiple AliasThis is currently unimplemented.

Здравствуйте, Cyberax, Вы писали:

C>JSP в Java, как и куча других *SP. Есть даже C++ Server Pages со встроенным С++.

Да, направление мысли правильное, но:

1. Всякие JSP и им подобные — это всё же не отдельный язык шаблонов (типа jade или haml), а просто html (т.е. куски текста по сути) со вставками кода.
2. У большинства *SP быстродействие используемого языка (собственно у всех, кроме C++) не сравнимо с D.
3. Далеко не у всех *SP имеется в наличие подобный асинхронный сервер.

Т.е. в данном случае vibe.d ближе скорее к node.js (с jade и т.п.), чем к jsp. Только с поправкой на использование высокопроизводительного статически типизированного компилируемого языка вместо JS.

Здравствуйте, Ikemefula, Вы писали:

I>Yet another template engine

Ну в общем да. Только с использованием высокопроизводительного статически типизированного компилируемого языка — это уже не такая обычная вещь. )))

I>Это сказки. vibe это как Node.js только на D и с меньшими возможностями.

Ну да, пожалуй он ближе всего к node.js. Только при этом благодаря используемому языку он:
1. Заметно быстрее (ну тут понятно всё)
2. Заметно надёжнее (благодаря строгой статической типизации и компиляции)
3. Заметно удобнее (благодаря мощному метапрограммированию — я это уже реально использовал).

Здравствуйте, DarkEld3r, Вы писали:

DE>Впрочем, один момент всё-таки не очень:
DE>

DE>int i = {10}; // int
DE>auto a1 = 10; // int
DE>auto a2 = {10}; // initializer_list
DE>

DE>Логично, но инициализация получается не такая и "uniform".

Ну да, первый вариант явно лишний. Кстати, он в современных реалиях записывается ещё и как int i{10};

Здравствуйте, DarkEld3r, Вы писали:

DE>В принципе, да (реально забыл про эту возможность). Только, к сожалению, не "решается", а "решится когда-нибудь":
DE>

DE>Note: Multiple AliasThis is currently unimplemented.

Ну для пары классов и сейчас вполне работает.

Здравствуйте, alex_public, Вы писали:

_>Ну в общем да. Только с использованием высокопроизводительного статически типизированного компилируемого языка — это уже не такая обычная вещь. )))

Для малопопулярных статически типизированных языков вполне обычная:

OCaml — Ocsigen
F# — WebSharper

Здравствуйте, FR, Вы писали:

FR>Ну для пары классов и сейчас вполне работает.
Действительно. Когда писал, то что-то не подумал, что от одного класса можно отнаследоваться.

Здравствуйте, alex_public, Вы писали:

_>Да, направление мысли правильное, но:
_>1. Всякие JSP и им подобные — это всё же не отдельный язык шаблонов (типа jade или haml), а просто html (т.е. куски текста по сути) со вставками кода.
Такое тоже было, для Java в том числе. Есть даже для Питона (mako), с JIT'ом от PyPy будет сравнимо с D.

_>2. У большинства *SP быстродействие используемого языка (собственно у всех, кроме C++) не сравнимо с D.
JSP компилируется в Java, которая работает быстрее D. В частности, из-за нормального мусоросборщика, а не D-шного угрёбища.

_>3. Далеко не у всех *SP имеется в наличие подобный асинхронный сервер.
И шо? 99% всего софта тупо генерируют страничку целиком и отдают её серверу, который потом на досуге отправляет её в сокет (может и асинхронно).

Здравствуйте, alex_public, Вы писали:

_>Ну да, первый вариант явно лишний.
Я немножко про другое — новая "универсальная" иницизация ещё и гарантирует отсутствие приведений типа. Было бы логично её везде применять, в том числе, и в связке с auto, но "внезапно" вылазит initializer_list.