и?

я разве против использовать свойства в ui?

Просто это выходит куда морочней

не согласен со "степенью мороченности" )

Ну одно дело, когда надо 5-10 свойств

но в целом на первый взгляд достаточно муторно писать protected int _field; public ref inout(int) field() inout @property { return _field; } вместо public int field { get; set; }

но в целом на первый взгляд достаточно муторно писать protected int _field; public ref inout(int) field() inout @property { return _field; } вместо public int field { get; set; }

Это при дефолтной логике

Если же надо уведомление, то в ди все еще печальней

только миксины

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

Мне нравится, когда работая с языком где подобное принято, тебе надо написать большой класс с кучей свойств. И тебе предлагают использовать "средства IDE" для генерации этого кода. Спрашивается зачем тогда это писать, если оно всё равно будет автогенерировано?

Если же надо уведомление, то в ди все еще печальней

печально в сравнении с C# для конкретной задачи

печально в сравнении с C# для конкретной задачи

в целом сейчас с этим удобно работать в котлине и языки с макросами

Потому что в каждом свойстве надо вызывать OnSetProperty(propertyName, value)

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

Так можно и динамических языков дойти :)

Они и идут друг к другу по мере возможностей

Уже даже в D то ли появилась то ли планируется динамическая компиляция в рантайме, где-то читал

Потому что в каждом свойстве надо вызывать OnSetProperty(propertyName, value)

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

мне например не упёрлось это совсем)

Ну просто никогда ui не делал

много мыслей по поводу D есть на тему "а я вот всю жизнь работаю на языке X и вот в X прям удобно что жесть, давайте в D так же!?"

вручную указывать обновление ui вообще грустно

Ну просто никогда ui не делал

правда?

правда?

образно говоря

образно говоря

не образно говорю что пилил даже свой ui на opengl

и там я делал как раз то, про что ты говоришь

свойства и их обновление

сигналы разные

вот только сейчас я этим не занимаюсь

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

О, кажется у нас появилась еще одна платиновая тема

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

Это я указал конкретный случай

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

Ну первая часть, в общем то, бред

D как раз должен быть запилен подо что то конкретное

Очередное "ни рыба, ни мясо" - плохо

D как раз должен быть запилен подо что то конкретное

я бы назвал это бредом

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

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

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

Но они хоть под что-то подходят

Но они хоть под что-то подходят

ну, следуя такой логике, D ни для чего не подходит в чём тогда твой интерес к нему?

D всяко удобнее плюсов, но желание сделать из него панацею его убивает

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

постоянно ломать обратную совместимость — плохая практика, как показала история самого D

Я предлагал менять синтаксис?

А C# под что конкретное заточен?

Он впринципе тоже обобществленный язык

Под винду

Я предлагал менять синтаксис?

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

Он впринципе тоже обобществленный язык

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

короче, не надо из D делать другой язык, это мой основной мессадж в этом разговоре)

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

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

Ну тогда поясню мысль. Я не имею ввиду то, что язык должен быть не общего назначение. А об системе целей создателей языка. Причем цели совпадающие с каким то реальными задачами. То есть вот та фича для языка важнее, чем вот эта. Без них получается непоследовательное прокачивание всего и всея. Получается либо огромная свалка-молотилка по типу Питона и Джавы, либо какой-то оторваный от жизни язык

Ну тогда поясню мысль. Я не имею ввиду то, что язык должен быть не общего назначение. А об системе целей создателей языка. Причем цели совпадающие с каким то реальными задачами. То есть вот та фича для языка важнее, чем вот эта. Без них получается непоследовательное прокачивание всего и всея. Получается либо огромная свалка-молотилка по типу Питона и Джавы, либо какой-то оторваный от жизни язык

так всем не угодишь

так всем не угодишь

И пытаться не надо

О том и речь

кому-то какжется, что D это не убийца C++ и вообще у него своя тема, кто-то считает, что нужно в D как Go сделать свой внутренний эвентлуп с автоматически расставляемыми в коде yield'ами и тд

а кому-то betterC кажется киллерфичей

И каждый тянет одеяло на себя

Кстате, на тему Odin и Jai, есть еще Zig: https://ziglang.org/

кому-то какжется, что D это не убийца C++ и вообще у него своя тема, кто-то считает, что нужно в D как Go сделать свой внутренний эвентлуп с автоматически расставляемыми в коде yield'ами и тд

Но впринципе не вижу причину почему бы не удовлетворить потребности всех )

Язык то вполне позволяет

И на betterC писать и eventloop сделать

Но впринципе не вижу причину почему бы не удовлетворить потребности всех )

Это все надо поддерживать

Язык то вполне позволяет

я то к тому же

Поддержим

не нужно делать перекоса в конкретности

Поддержим

Пока существующее поддерживается кое как

ERROR: S client not available

Ну тогда поясню мысль. Я не имею ввиду то, что язык должен быть не общего назначение. А об системе целей создателей языка. Причем цели совпадающие с каким то реальными задачами. То есть вот та фича для языка важнее, чем вот эта. Без них получается непоследовательное прокачивание всего и всея. Получается либо огромная свалка-молотилка по типу Питона и Джавы, либо какой-то оторваный от жизни язык

насчёт целей, как мне кажется нужно чаще появляться на офф форуме и высказываться там на тему развития языка

ну или тут сформировать общую точку зрения (не по всем аспектам, конечно), которая не совпадает с текущим положением и вынести на обсуждение туда 'от имени коллектива русскоговорящих в тг'

насчёт целей, как мне кажется нужно чаще появляться на офф форуме и высказываться там на тему развития языка

Будет как в шутке про 11 конкурирующих стандартов

Будет как в шутке про 11 конкурирующих стандартов

так я и говорю, что не по всем аспектам

какое-то общее недовольство всё равно имеется

так я и говорю, что не по всем аспектам

Проблемы это не решит. Кто то должен за всех решить, куда D катить

Ну или плюнуть, форкнуть и надежно приклеить скотчем

Проблемы это не решит. Кто то должен за всех решить, куда D катить

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

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

Ну это случай, когда коммьюнити говорит нет

Коммьюнити пока что не выбирает путь развития D

Выбирает, они же провдили опрос который повлияет на приоритеты

кто-нибудь использует D для написания кроссплатформенных скриптов (вместо баш/батников)? какие преимущества по сравнению с питон/tcl/perl скриптами (кроме скорости)?

кто-нибудь использует D для написания кроссплатформенных скриптов (вместо баш/батников)? какие преимущества по сравнению с питон/tcl/perl скриптами (кроме скорости)?

по сравнению с питон/tcl/perl приятный читабельный код

по сравнению с питон/tcl/perl приятный читабельный код

От человека зависит

по сравнению с питон/tcl/perl приятный читабельный код

я думаю, что тем, кто пишет на плюсах, но не знает скриптовых языков, D может помочь в плане скриптов.

я думаю, что тем, кто пишет на плюсах, но не знает скриптовых языков, D может помочь в плане скриптов.

Писать скрипты на С++ такое себе удовольствие

Писать скрипты на С++ такое себе удовольствие

я понимаю. я к примеру, говорю про сателлитные вещи: например, оформить скрипт для запуска CMake с кучей параметров на языке D :)

я понимаю. я к примеру, говорю про сателлитные вещи: например, оформить скрипт для запуска CMake с кучей параметров на языке D :)

Проще написать без CMake

я думаю, что тем, кто пишет на плюсах, но не знает скриптовых языков, D может помочь в плане скриптов.

Сомневаюсь, есть ли такие.

кто-нибудь использует D для написания кроссплатформенных скриптов (вместо баш/батников)? какие преимущества по сравнению с питон/tcl/perl скриптами (кроме скорости)?

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

Сомневаюсь, есть ли такие.

я такой :). Пишу на C++ программы. Вот и экспериментирую с D для скриптов.

я такой :). Пишу на C++ программы. Вот и экспериментирую с D для скриптов.

через dub же?

через dub же?

у нас CMake для C++. А скрипты D пока с rdmd используются.

у нас CMake для C++. А скрипты D пока с rdmd используются.

просто почти так же можно dub'ом запускать, только появляется возможность другие пакеты использовать

ну эт если вдруг не знает кто, на заметку

просто почти так же можно dub'ом запускать, только появляется возможность другие пакеты использовать

Ну тогда нужен полноценный пакет делать

Ну тогда нужен полноценный пакет делать

я про single file packages http://code.dlang.org/advanced_usage

я про single file packages http://code.dlang.org/advanced_usage

Впервые слышу

скрипты должны уметь шебанг, - Ди может?..

скрипты должны уметь шебанг, - Ди может?..

С недавних пор

ок

Но --shebang опция rdmd не работает