а то вот jvm подход - все ссылка мне не нравится

Не верю что там нет каких-то штуковин как структуры по поведению

Не верю что там нет каких-то штуковин как структуры по поведению

Только примитивы

то есть Int, Float, Boolean

и все

А что тогда тебе мешает просто писать на D, не используя in/out для себя?

отсутствие нормального автокомплита

А, автокомплита нет

Ну для своего ты тоже его будешь пилить год )

ну для самообразования норм =)

пока студент - могу позволить

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

или ufcs

с шаблонами

Ну это тогда go получится

Ну это тогда go получится

Нееееее

Я вообще, не знаю, что с памятью делать

gc сам не напишу

эт точно

адекватный

Я вообще, не знаю, что с памятью делать

Свои аллокаторы.

Свои аллокаторы.

как это красиво и для дураков(меня) это сделать?

Это стремление за красотой ни к чему не приведёт.

Свои аллокаторы без особого синтаксиса ломают автокомплит конструктора

Это что за структуры такие с конструкторами?

Даже в том же D они есть

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

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

Потому что проявится это только в рантайме

Или странной ошибкой в кт

но это лично мои желания

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

Но эт уже сказки

Посмотри на существующие языки, типа, Odin.

насколько сильно от net framework отличается?

Тот же .NET просто урезаный

Посмотри на существующие языки, типа, Odin.

Чет сильно на раст смахивает

jai тоже посмотри, как раз для игр разрабатывается.

https://github.com/BSVino/JaiPrimer

глянул

Жаль nemerle чет неживой

интересная штука получалась

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

то что ufcs не хавает?

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

нереализуем нормальный

шаблоны слишком мощные

"нормальный" как раз реализуем

от слова "норма" — как у всех

ну смотри, ufcs и mixin уже много отрезают

хотя я вот тут заметил, что mixin'ы разворачиваются норм

mixin чуток поддерживался в mono-d, как и ufcs

ну не полностью поддерживаются, ну и что?)

Все, невозможно кодить теперь )

теперь энергию съеденной пищи перерабатывать в новый язык?)

может чёт полезное лучше сделать?)

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

может чёт полезное лучше сделать?)

что именно?

автокомплит в D?

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

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

автокомплит в D?

такой чтобы устраивал

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

ну так тем более

покопаться в компиляторе существующем, разобраться что там и как

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

короткий синтаксис эт что вообще?

короткий синтаксис эт что вообще?

как в шарпе например public int Count {get; set;}

воо, вопрос: что это за хрень?

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

просто public int count;

ERROR: S client not available

а если только get нужен?

а set только приватный?

или, что хуже, протектед сет

не так уж много кода, тем более можно решить с помощью mixin'ов

если уж совсем не вмоготу

не так уж много кода, тем более можно решить с помощью mixin'ов

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

А если реализовывать какой-нибудь mvvm, то там вообще онли проперти используются

а язык то свой решит эти вопросы?

идеи есть

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

Я щас уже не помню, но там реально есть разница между публичным полем и приватным полем с геттером и сеттером

Причем лучше использовать второй вариант

Вот я тоже не помню почему

"так правильно"

но все чисто ооп языки только с помощью свойств общаются

а на практике это реально нужно 1 раз 100 случаев

в скале и котлине вообще нет полей

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

с обычным публичным полем этого не сделать

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

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

С наследованием ясность пропадает

не думаю

https://softwareengineering.stackexchange.com/questions/161303/is-it-bad-practice-to-use-public-fields

https://softwareengineering.stackexchange.com/questions/161303/is-it-bad-practice-to-use-public-fields

и?

"В .NET не принято"

а на практике это реально нужно 1 раз 100 случаев

Тут хотя бы 1 на 1000..

"В .NET не принято"

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

"вы можете легко добавить дополнительный код в setter" и на деле получается тот же синтаксис по объему что и в D

"вы можете легко добавить дополнительный код в setter" и на деле получается тот же синтаксис по объему что и в D

на деле мы можем его переопределить в любой момент

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

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

я не против свойств в целом

я против бездумного следования каким-то правилам