W
Если не полностью, впрочем
Size: a a a
2020 November 25
W
А не, в фарше есть DU на структах
IC
DU только для привлечения внимания. Оригинальный вопрос был аж в пятницу.
https://t.me/pro_net/295824
https://t.me/pro_net/295824
I
А не, в фарше есть DU на структах
Но именно на структах реализовано плохо
W
Ну а там видимо никто не придумал ответа
W
Igor
Но именно на структах реализовано плохо
А я вообще хз как такие вещи на структах робят
A
Есть же пропозал по DU, почитай да и всё
За четыре года только пару раз упомянули проблему с overlap. Поди как всегда закончится, language team будет ссылаться на проблемы в рантайме, runtime team будет ссылаться на проблемы в языке
MA
Никто не обходил новый клаудфаер программно?
MA
Там где скрипт качается отдельно и в ответе не цифры , а буквенная последовательность
A
Есть же пропозал по DU, почитай да и всё
Да и если посмотреть оригинальный пропозал про DU, то там речь о закрытых иерархиях типов, типа OneOf{ A, B} порождает типы OneOf c конкретными наследниками OneOf.A и OneOf.B
Простенький TU ж чисто про композицию, ни A ни B никак не завязаны на Either<A,B>
Простенький TU ж чисто про композицию, ни A ни B никак не завязаны на Either<A,B>
K
Господа байтоебы и знатоки утечек
В фиолетовом обсуждаем
подскажите надо ли диспозить CancellationTokenSource
В фиолетовом обсуждаем
подскажите надо ли диспозить CancellationTokenSource
Кроме linked token source надо ещё помнить про таймер/таймаут. Если ничего из этого нет, то диспоузить не обязательно.
VS
Aloraman
Наброс про abstract struct довольно быстро потонул, видимо надобно что-то поближе к функциональщине.
Например, поддержка tagged union со стороны рантайма! (Не полноценные sum type, Either<A,A,B> и Either<B,A> - разные типы. но все ж)
Если их ручками реализовывать, то натыкаешься либо на аллокации, либо на жирненькость.
Имплементация должна содержать индекс реального значения (tag) и множество возможных значений, из которых задано только одно (вот отсюда возникает оверхед по используемой памяти)
- Если имплементирован как value-тип, то передавать его дорого, приходится возиться с ref return и ref/out параметрами
- Если имплементирован как reference-тип, то место передавать дешево, но нужно сделать аллокацию, да и в куче место отожрет
Можно попробовать уменьшить занимаемое место, как-то сделав overlap участков памяти под конкретные значения:
- В tagged union одно поле object под все значения, а по индексу уже определяем, что за конкретный тип. Постоянный боксинг/анбоксинг и тайпчеки!
- Включаем байтоебство, и FieldOffset'ами записываем все значения по одному смещению, и по индексу вытаскиваем конкретные байтики. Все хорошо пока все значения или только value-типы или только reference-типы. Как только натыкаемся на оба получаем E-E-Exception! Нельзя оверлапить ссылки и данные, для GC нужно обязательно гарантировать, что в этом участке памяти ссылка в кучу может быть либо всегда, либо никогда!
То бишь для стройного быстрого tagged union нужна реализация со стороны рантайма, и что б GC знал, что надо индекс проверять перед тем как ссылки переписывать.
Что думаете? Где возникнут type holes, GC holes, etc?
Например, поддержка tagged union со стороны рантайма! (Не полноценные sum type, Either<A,A,B> и Either<B,A> - разные типы. но все ж)
Если их ручками реализовывать, то натыкаешься либо на аллокации, либо на жирненькость.
Имплементация должна содержать индекс реального значения (tag) и множество возможных значений, из которых задано только одно (вот отсюда возникает оверхед по используемой памяти)
- Если имплементирован как value-тип, то передавать его дорого, приходится возиться с ref return и ref/out параметрами
- Если имплементирован как reference-тип, то место передавать дешево, но нужно сделать аллокацию, да и в куче место отожрет
Можно попробовать уменьшить занимаемое место, как-то сделав overlap участков памяти под конкретные значения:
- В tagged union одно поле object под все значения, а по индексу уже определяем, что за конкретный тип. Постоянный боксинг/анбоксинг и тайпчеки!
- Включаем байтоебство, и FieldOffset'ами записываем все значения по одному смещению, и по индексу вытаскиваем конкретные байтики. Все хорошо пока все значения или только value-типы или только reference-типы. Как только натыкаемся на оба получаем E-E-Exception! Нельзя оверлапить ссылки и данные, для GC нужно обязательно гарантировать, что в этом участке памяти ссылка в кучу может быть либо всегда, либо никогда!
То бишь для стройного быстрого tagged union нужна реализация со стороны рантайма, и что б GC знал, что надо индекс проверять перед тем как ссылки переписывать.
Что думаете? Где возникнут type holes, GC holes, etc?
Месье имеет очень странные вкусы.
A
Месье имеет очень странные вкусы.
Не все ж наворачивать Model -> DbSet -> DbContext -> Repository -> Dto -> ApplicationService -> ViewModel -> Controller в крудах
VS
Aloraman
Не все ж наворачивать Model -> DbSet -> DbContext -> Repository -> Dto -> ApplicationService -> ViewModel -> Controller в крудах
Я бы посоветовал посмотреть на фшарп
I
Aloraman
Да и если посмотреть оригинальный пропозал про DU, то там речь о закрытых иерархиях типов, типа OneOf{ A, B} порождает типы OneOf c конкретными наследниками OneOf.A и OneOf.B
Простенький TU ж чисто про композицию, ни A ни B никак не завязаны на Either<A,B>
Простенький TU ж чисто про композицию, ни A ни B никак не завязаны на Either<A,B>
Ну в фаршике сейчас как раз такого вида DU. Делают пропозал на второй тип, который ты описал, аля (int | string)
VS
А не страдать херней
A
Я бы посоветовал посмотреть на фшарп
Мы вам перезвоним
I
Не совсем пока понимаю какого рода поддержку от рантайма ты хочешь увидеть
VS
Aloraman
Мы вам перезвоним
Написанное выглядит как некоторый бред просто. Я предлагаю посмотреть, как это сделано по-нормальному
I
Написанное выглядит как некоторый бред просто. Я предлагаю посмотреть, как это сделано по-нормальному
так он же в начале описал 1 в 1 DU в фарше