Как стать автором
Обновить

Комментарии 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;
    }
}

И закрыть тикет).
srq (x) => x*2 — и закрыть тикет — это сильно, конечно :)
Как с BDD?

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

Мы используем dstep в «боевом» коде при сборке: .proto -> protobuf-compiler -> dstep, экономит много времени при изменении файлов .proto
Добавил в пост ссылку на вашу статью о dub, почему-то она прошла мимо меня при публикации.
Есть так же серия статей от Майка Паркера (Derelict). Там неплохо разъясняются основные подводные камни.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории