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

как не имеет смысла

надо бить по рукам за nullable

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

Есть третий вариант — завести struct du.

на самом деле я так и сделал)

но если бы были совместимы строка и nullable, то возможно не делал бы

>делать лишние типы просто ради того чтобы их обрабатывать

на самом деле я так и сделал)

Это хорошо. :)

а зачем тебе option тогда вообще?

Просто ещё null возможен

откуда

если ты не работаешь с C# кодом то у тебя никаких null нигде быть не должно

если ты не работаешь с C# кодом то у тебя никаких null нигде быть не должно

Reflection

Правило простое. От null нужно избавляться прямо в месте его появления.

Это да

не понимаю смысла оборачивать в лишние типы

Вообще да, идея со своим DU хорошая. Удобно + сразу отпадает "запутывание"

Правило простое. От null нужно избавляться прямо в месте его появления.

если у тебя поле string, null может придти на десереализации или еще откуда угодно из стороннего сервиса

если у тебя поле string, null может придти на десереализации или еще откуда угодно из стороннего сервиса

Да, и прямо там нужно от него избавиться.

прямо там это где?)

DU это ADT?

После десериализации или получения ответа от стороннего сервиса.

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

DU это ADT?

Да.

ну вот. Неудобство)

Небольшая плата за null safety.

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

а зачем option

если тип строки уже включает возможный вариант ее отсутствия

а зачем option

C# библиотеки для сериализации работают с null, но плохо работаю с ADT.

Приходится делать немного дополнительной работы.

C# библиотеки для сериализации работают с null, но плохо работаю с ADT.

а нет своей на F#?

Есть конвертеры, конечно. Для того же Json.NET

У Vladimir серьезные требования по перформансу.

Я не знаю, что сейчас используется, и как это работает с типами F#.

сейчас переписал BindQueryString из жирафа

https://github.com/Lanayx/PerformanceTest/blob/Parser/src/Parser.fs

а зачем использовать F# если очень важна скорость?

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

затем что можно и F# использовать несмотря на скорость)

а зачем использовать F# если очень важна скорость?

Потому что можем.

Обожаю этот ответ

Я добавлю немного контекста. Vladimir участвует в HighLoad Cup. Почему бы не F# + Kestrel? :)

Я не вижу ни одной причины не использовать такой стек.

аа это

while true do Прочитал про ЯП->понял, что это не серебрянная пуля->пошёл читать про другой яп

почему не рекурсивная функция

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

Там все равно лучше не через tryParse делать

а как строку к числу преобразовать да еще и без эксепшна?

Ну довольно просто

На самом деле

Ща

или ты про httpContext.Request.Query.TryGetValue ?

Int32.TryParse ?

Да

int32.TryParse

Он не слишком эффективен

Там техника вычитания из чара значения 0x30

И надо проверять, что он меньше 9

Или равен

Дальше умножение на нужную разрядность всего, что получилось

https://ayende.com/blog/176034/making-code-faster-the-interview-question

В блоге есть техника

есть код?) с нуля реализовывать точно не буду

https://ayende.com/blog/176037/making-code-faster-going-down-the-i-o-chute

там нужен имеено TryParse

Ну всегда можно дописать

Же

Возврат из цикла

В виде кортежа

Один if

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

и переполнения инта

Минус по идее значит, что не распарсилось

я про такой минус -200

Там техника вычитания из чара значения 0x30

Я эту технику в школе на паскале использовал еще)

Плюс если за миллион перевалило, то тебе дальше не надо

это тоже инт)

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

Те, которые больше миллиона с чем-то и меньше нуля

так -200 это валидный инт

мне такие приходят)

ибольше миллиона тоже

там таймстемпы фигачат

Миллион - задаваемое ограничение парсинга

Нижняя граница у тебя 0

я и говорю что его не нужно задавать)

Верхняя плавает

Но пользователей ты знаешь максимум

и нижняя граница тоже может быть минус миллион)

Локейшнов тоже

И визитову

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

или даже в лонгах

Ну для таймстемпа парс лонга

Там разницы нет

В алгоритме

Идешь по циклу

Проверяешь, чтобы не больше верхней границы

И чтобы цифра <=9

Если условие не выполняется, возвращаем false,x