имхо, писать будет неудобнее, чем то, что я предложил

возможно, не помню как правильно реализовать... в руби то просто переопределяешь и всё

Александреску листаю чегото никак не соображу что тут уместнее и красивее

Сорри, я с работы не очень словоохотлив на мобиле) погугли mixin template (не путать с функцией mixin()), поймёшь, то или не то. но по смыслу весьма похоже на «импорт метод»

Вообще если класс большой получился, то вероятно он перегружен и нуждается в рефакторинге. Он должен делать одну вещь хорошо. Опять-таки это субъективно. Я придерживаюсь SOLID. Возможно Вы придерживаетесь другой идеи, KISS или чего-то еще.

А через наследование? Пусть и лишние , неиспользуемые классы породит

Скорее всего qwe прав

И в этом плассе по-сути несколько классов просто

класс не такой уж большой, просто в конкретном случае выделение в отдельный файл дало бы более элегантное понимание со стороны, когда не трогаешь проект долго

Мм. Обычно нужно видет класс полностью, а вот члены других классов видеть не требуется. Так как красс работает по большей части с собственными методами и обращается к собственным полям.

Класс может быть большой но примитивный, и тогда редактор должен сворачивать методы чтобы было красиво :)

Или .h файлы :)

по сути видимо импортировать в основном модуле описывающем класс модули с методами чтоли...

можно делать как в С++ https://dlang.org/dmd-linux.html#interface-files

да, я решил свою проблему проще... тк у меня синглтон, переменные все статичные, то импортированые методы вполне могут и напрямую обращаться, эти методы просто в модули вынес

mixin template - тут чересчур тк разовый код, преднастройка скажем *.di - по мне так излишнее описание

а вариант с методами, объвленными как функции, почему не?

так по сути и сделал, только передавать в функции объявленные в модуле экземпляр класса не было надобности - переменные статические

грубо говоря у меня есть класс синглтон UI и есть муторные build методы, чисто визуально решил их вынести, чтобы UI был читабельным и помещался в экран-два

грубо говоря у меня есть класс синглтон UI и есть муторные build методы, чисто визуально решил их вынести, чтобы UI был читабельным и помещался в экран-два

Хм, а почему не наследовать в этой ситуации?

есть смысл?

Да и что в ui кроме build методов может лежать?

)))

описалово в основном конечно

Логика в ui не есть хорошо

логики и нет

А что за либа для ui?

в текущей реализации gtk

но вообще UI своего рода адаптером предусматривается

Без builder'а?

имеешь ввиду строить по glade файлу?

Да, я так делал всегда

Мне кажется очень удобно

тоже раньше делал, а сейчас императивно чото взбрело

Ну... Так то... Дело вкуса конечно...)

говорю долго за программирование за пределами веба не выходил, работой завалило... вот вспоминаю

А что за задача, что не вебом решаема?

вообще я 98% по вебу ) а дэсктопы всякие, мобайлы это ж интересно тоже из виду не упускать, вот для себя делаю каркас

есть пара задумок которые придётся реализовать не только как веб

хотя и сеть там в центре

Постепенно пришел к выводу, что всё что работает с сетью может быть вебом

Да и коммерческая разработка сейчас веб в основном

в идеале хочу сделать такой каркас, чтобы dsl уровень крутился по типу сервиса а вьюхи адаптерами подгонялись под нужды

а по центру замутить очередь событий

Хм... А это случаем не html получиться под другим соусом?

возможно )

но это больше для себя, поэтому велосипеды разрешены

хотя html его назвать никак не получится, тут абстракция другая, не единым языком вьюзу стряпать, а делать нативную вьюху для каждой из платформ скорее

скажем так что одна софтина будет по вебу выглядеть как http-api, на дэсктопе как например x11/gtk, на мобиле под своим соусом

или под WebView

что-то в духе «декрарируем задачу, а платформа подбирает виджеты для реализации»?

Просто были такие идеи у меня тоже, но по сути это реализация html+css+js

ну наверное можно и так сказать

JS - по сути в кроссплатформе всюду в виде WebView и Chromium

Когда ты с сервера отправляешь то что должно отобразится как интерфейс у пользователя

С другой стороны это интересно в качестве альтернативного подхода к сетевым приложениям

в моём случае веб-вью будет представлять HTML/CSS/JS, сам каркас даст нечто типа HTTP-API, доставку/рендеринг вебвью он на себя не берет

если нужно будет отдавать представление по сети, то приложение будет запущено в виде демона, который в свою очередь как обычно можно повесить на отдачу например nginx

вебвьюху тоже выложить через nginx

но этот же набор кода за исключением адаптера вьюхи чтобы можно было повторно использовать для дэсктоп и для мобилы

стандартные замашки в общем то

разница на дэсктопной сборке будет в адаптере gtk (например) вместо http-socket

хз конечно что получится

в общем если что получится опубликую, фиг знает хватит ли мотивации )

пока так, в виде вспоминания D

Ждём)

Fiber аналог генератора из Python?

Не совсем

ERROR: S client not available

Генератор может возвращать значение, а файбер больше похож на поток

тогда получается совсем не генератор, если похож на поток)

аа, кажется, понял

такой поток, который можно приостановить и запустить с того же места

круто

yield как раз приостанавливает, но не возвращает

Хотя не вчитывался, может можно и значение вернуть

Вот как сервисы, живущие за счёт того что предоставляют машиночитаемые данные могут быть такими идиотскими и без какого-либо уведомления брать и менять формат этих данных (это при том, что даже документацию нормальную написать не осилили, типа смотрите xml и так все понятно). Взяли и поменяли местами элементы. Раньше можно было прочитать содержимое того, что шел вначале, составив из него хеш-таблицу, а затем для последующих по этой хеш-таблице замену делать. И всё в потоковом режиме, в памяти только эта самая таблица мегабайт на пятьдесят, да текущая обрабатываемая сущность на полмегабайта. Теперь же всё наоборот, одной памятью не отделаться и нужно сначала десятки тысячь этих полумегабайтных сущностей в какую-то временную базу складывать только для того, чтобы потом опять достать, получить айдишники из некоторых полей, получить из последующих элементов значения по этим айдишникам и, условно говоря, заменить айдишники на значения (на самом деле на айдишники из своей базы) и уже вот это сохранять в целевой бд. И ладно бы с ними с дополнительными сложностями (кому-то может наоборот облегчило, ибо без понятия кто как это всё использует), но это совершенно непредвиденные работы по переписыванию готового оттестированного и отдебаженного кода.

Единственный выход - сделать конкурента с неизменяющимся форматом

Ну да. И вместо того, чтобы заниматься своим делом, приходится делать и то и другое и третье. И угля добуть и паравоз почини и мост построй, а потом уже можешь поехать (разумеется в роли машиниста) и отвезти бурёнок в соседнюю деревню к бычку на осеменение. Ой, стрелку же надо было перевести, чтож заранее то не сбегал не перключил? Кто едет тот и переключать должен.

Прошу прощения

Ну да, интернет он такой =)

Хотя, можно попробовать просто написать им гневное письмо. Не исключено что они где-то припасли старое апи со старым форматом

И выдают его гневным

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

Да, проджект уже этим занят

Большие проекты так и разрабатываются, я щас разгребаю горы легаси. Сам удвиляюсь как это все работает.

Всю систему тут удобнее себе представлять как пластилин, нежели как жесткую единообразную конструкцию. В одном месте дописал функцию, пусть даже это третья функция которая делает то же что и две другие, но это работает.

Да, мы тут пару фич переосмыслили. Пару раз. Пару раз переписали. В итоге второй месяц натыкаюсь на редкие случаи, когда срабатывает какой-то забытый старый код для одной из версий и получается что-то удивительное, крадущееся мимо тестов словно ниндзя в ночи.

Потому как на пару десятков методов есть по несколько клонов, делающих или ровно тоже самое или пооочтиии тоже самое.

Кроме того есть бермудский треугольник, который создал один товарищ, не захотевший разбираться с тем как принято всё делать в остальном проекте и, начхав на негласный "стандарт", сделал собственную песочницу, вместо обращения к имеющемуся апи налепил собственных реализаций того-же самого, но выполненного с другим подходом. В итоге какое-то время после любых изменений звали его чтобы он свою часть соответственно поправил, но в конце-концов он и сам уже не смог её поддерживать и ей планируется ампутация с переписыванием.

Кто-нибудь может подсказать что указывают параметры метода? https://dlang.org/phobos/std_socket.html#.Socket.select

checkRead, checkWrite, checkError

А вышло так потому как ему вначале было проще свелосипедить, чем заглянуть в код или просто спросить "а как вот это нужно сделать? есть для этого что-нибудь?"

Кто-нибудь может подсказать что указывают параметры метода? https://dlang.org/phobos/std_socket.html#.Socket.select

Так это же походу классический асинхронный select. Ты передаешь туда множества сокетов, а метод в каждом множестве проверяет каждый сокет на возможность прочитать оттуда, возможность записать, и наличие ошибок соответственно.

SocketSet переводится как "множество сокетов" в данном случае

qwe Насколько я понял он проверяет идмения статусов сокетов из этих самых SocketSet'ов, возвращает сколько их изменилось и обновляет SocketSet'ы чтобы в них содержались только изменённые (хотя я похоже неправильно это понял). В таком случае этот селект может принимать три SocketSet'а, первый проверять на чтение (видимо есть ли что читать), второй на запись, тертий на ошибки.

А, ну почти

Привет всем. Подскажите реализация event queue в dlang с покером и прочим есть какая? Вижу std.signals, но это похоже observer.

http://code.dlang.org/search?q=event из этого ничего не подходит?

может просто я не про то думаю?

http://dlang.org/phobos/std_concurrency.html#.send вот тут сообщения пересылаются другому потоку, с сетью не связанно