Comments 17
Ожидал увидеть еще рекомендации по написанию bindings, местами бывают нетривиальные или неочевидные проблемы. Как например, глобальные переменные должны экспортированы вот так:
extern(C) extern __gshared int my_global_int;
Честно говоря, я вряд ли что смог бы прояснить по вопросом написания bindings. Сам не так давно увлекся этим языком. Разбираюсь в основном с возможностями написания асинхронного сетевого кода, реализацией coroutine на Fiber и интерфейсом с CPython.

Биндинги сам не пробовал писать, все что меня пока интересует уже есть в проектах Deimos и pyd. А при разборе кода заинтересовавших меня bindings, черпал информацию отсюда.
Ух ты, наконец-то оформили в отдельную страничку то, что приходилось собирать по новостной группе.

Итого вы работаете с vibe.d? Сопрограммы, правда, я там не видел в чистом виде. Я его использую для синхронизации рукописных кешей для бд, очень уж удобно устроен rest-api. Также все приглядываюсь к SCTP, если реализовать его сокеты для vibe.d, то можно будет не велосипедить на UDP стриминг голоса/видео и игровых данных.
Итого вы работаете с vibe.d?

Нет, с vibe.d кое-что пробовал делать, но в целях самообразования решил запилить собственный велосипед :). Перебросил кое-что более-менее не стыдное показать по теме асинхронной сети из приватной репы в проект на гитхабе. Там же есть и попытки реализации короутин.
Примеры для mercury выглядят элегантно, но, конечно, это простые демки. У вайба, как у большого проекта, появился один недостаток — там черт ногу сломит разбираться во многокилометровых модулях. Вот mercury хорошо демонструет ядро асинхронного IO.
У вайба, как у большого проекта, появился один недостаток — там черт ногу сломит разбираться во многокилометровых модулях.
Абсолютно верно. Использовать — да, очень удобно. Понять как это работает — практически нереально. Это и послужило толчком к велосипедо-строению. Так же хотелось попробовать реализовать концепцию разделения обработки клиентских подключений на логические уровни Transport, Protocol, как это сделано в twisted.
> Понять как это работает — практически нереально.

Готовлю длинный цикл статей о vibe.d, в том числе с объяснением деталей реализации (я автор некоторых модулей). Но жизнь всё отвлекает и отвлекает :)
Хочется знать больше о подходах и идиомах языка. К примеру:
1) В c++ проектах принято писать два исходника один *.hpp и другой *.cpp. Как в этом плане у D?
2) Какие возможности модульного тестирования? К примеру есть ли бэнчамаркинг аналогичный тому что в объекте testing языка go?
1) Исходник один, но при необходимость можно разделить описание интерфейсов от реализации в разные файлы.
2) Стандартными возможностями языка предусмотрено включение в код юниттестов. Кроме этого есть уже пакеты, которые облегчают написание тестов, например.
1) Значит как в Java. Разбить на interface и реализацию интерфейса. Все так?
2) Как с BDD? Ваше мнение какое о том как с этим у D?
1) Как и почти во всех остальных языках :) Да именно так, сам не пробовал. Не было пока нужды писать закрытый код, а фича эта не знаю для чего еще может быть полезна, кроме этого. В книге это определенно было описано, не могу сейчас вспомнить в какой главе, к сожалению.

2) Насчет BDD, Вы знаете какие-то языки программирования, которые эту фичу поддерживают «из коробки»? Я не знаю, был бы рад узнать. А то касается TDD, то в D ничего не мешает постановщику задачи отправит прогеру файл типа:
class Sqr {
}

unittest {
    auto sqr = new Sqr();
    assert (sqr.do(2) == 4);
    assert (sqr.do(3) == 9);
    assert (sqr.do(10) == 100);
}

И прогеру ничего не помешает добавить метод do:
class Sqr {
    int do(int value x) {
        return x * 2;
    }
}

И закрыть тикет).
Как с BDD?

BDD тут при чем? Это по сути методология разработки, а заимплементить Gherkin на D для функциональных/интеграционных тестов я думаю вопрос времени и желания.
Автоматическая генерация биндингов (plain C) возможна с помощью магической утилиты github.com/jacob-carlborg/dstep
Минусы: не будет идиоматической конвертации макросов
Плюсы: быстро, не нужно тратить время на поддержку

Мы используем dstep в «боевом» коде при сборке: .proto -> protobuf-compiler -> dstep, экономит много времени при изменении файлов .proto
Добавил в пост ссылку на вашу статью о dub, почему-то она прошла мимо меня при публикации.
Only those users with full accounts are able to leave comments. Log in, please.