Я, если честно, устал спорить с утверждением «10 десятичных цифр лучше чем 32 шестнадцатеричные». Окей, можете форкнуть репозиторий и исправить в своей копии.
Остаётся только один вопрос — зачем?
В мире нет ни одной реальной задачи, в которой доступ к уникодной строке требуется побайтно. В Расте банально вычислить количество уникодных символов между двумя байтовыми позициями — интересное такое занятие с неопределённым результатом.
Оперировать UTF-8 строкой как массивом уникодных символов невозможно в Rust. Ты можешь оперировать ей как набором указателей на место в буфере, где начинается какой символ.
В реальной жизни же уметь работать с UTF-8 строкой как с набором байтов не нужно вообще никогда.
Так я и пишу, что надо разрабатывать API так, чтобы у вебмакаки не было этой проблемы. Указывать дефолтное состояние чекбокса то бишь. И руки оторвать тому, кто придумал неинициализированное состояние системного чекбокса.
Хинт: если взять последние, ну скажем 6 знаков uuid-а — получится ровно то же самое длинное число. Админки, которые я видел, именно так и делали — последние n знаков показывали, полный uuid за спойлером.
Лично для меня Rust закончился, когда я осознал, что он не умеет в UTF-8. Совсем. Инженеры просто не подумали, им по традиции наплевать на неанглоязычных пользователей.
Найти подстроку, вставить подстроку, заменить подстроку, разбить по подстроке — пиши всё сам, итератор по символам к твоим услугам.
Вот что меня всегда поражало, можно даже сказать, восхищало, в русскоязычных форумах, так это апломб, с которым дилетанты излагают свою критику.
С вашего позволения, на сообщения в такой форме я отвечать не буду.
Так ровно это REST и предполагает ;) Принцип code-on-demand.
Следующая глава будет про интерфейсы, а вот через неделю планирую взяться за главу ‘Deconstructing the REST myth’
Ну как «разработано». Операции «сдвинь элемент массива на n позиций влево» там нет, например. Если б любая предметная логика описывалась просто правкой JSON-ов, я бы давно помер с голода.
Ну и не могу не отметить, что поле, принимающее три значения — true, false и null — это какой-то кадавр, независимо от наличия в языке удобных конструкций для работы с такой псевдотроичной логикой.
API (как и контрактное программирование в целом) нужен в том числе для того, чтобы разработчики клиента были свободны в выборе технологий и не зависели от моих личный желаний и предпочтений.
Хороший тон при разработке API — использовать для идентификаторов сущностей глобально уникальные строки, либо семантичные (например, "lungo" для видов напитков), либо случайные (например UUID-4). Это может чрезвычайно пригодиться, если вдруг придётся объединять данные из нескольких источников под одним идентификатором.
Так вот чтобы никого не оскорблять, должен быть явный пункт «предпочту не говорить» вместо неявного null.
Я, если честно, устал спорить с утверждением «10 десятичных цифр лучше чем 32 шестнадцатеричные». Окей, можете форкнуть репозиторий и исправить в своей копии.
thread 'main' panicked at 'byte index 1 is not a char boundary
Прекрасный способ отстрелить себе ногу.
Да каких конвертаций? Что станет хуже, если str[i] указывает на char, а не byte?
Остаётся только один вопрос — зачем?
В мире нет ни одной реальной задачи, в которой доступ к уникодной строке требуется побайтно. В Расте банально вычислить количество уникодных символов между двумя байтовыми позициями — интересное такое занятие с неопределённым результатом.
… поэтому будем массив байтов давать, ага.
Если разбить уникодную строку по графеме, получатся хотя бы две валидные уникодные строки, в отличие от.
Оперировать UTF-8 строкой как массивом уникодных символов невозможно в Rust. Ты можешь оперировать ей как набором указателей на место в буфере, где начинается какой символ.
В реальной жизни же уметь работать с UTF-8 строкой как с набором байтов не нужно вообще никогда.
А можно примеры продуманных решений в GraphQL? Единственное, что он умеет из списка — возвращать пустые массивы без ошибки.
Так я и пишу, что надо разрабатывать API так, чтобы у вебмакаки не было этой проблемы. Указывать дефолтное состояние чекбокса то бишь. И руки оторвать тому, кто придумал неинициализированное состояние системного чекбокса.
Хинт: если взять последние, ну скажем 6 знаков uuid-а — получится ровно то же самое длинное число. Админки, которые я видел, именно так и делали — последние n знаков показывали, полный uuid за спойлером.
Лично для меня Rust закончился, когда я осознал, что он не умеет в UTF-8. Совсем. Инженеры просто не подумали, им по традиции наплевать на неанглоязычных пользователей.
Найти подстроку, вставить подстроку, заменить подстроку, разбить по подстроке — пиши всё сам, итератор по символам к твоим услугам.
Спасибо.
Последний абзац прочитайте, пожалуйста.
Вот что меня всегда поражало, можно даже сказать, восхищало, в русскоязычных форумах, так это апломб, с которым дилетанты излагают свою критику.
С вашего позволения, на сообщения в такой форме я отвечать не буду.
Так ровно это REST и предполагает ;) Принцип code-on-demand.
Следующая глава будет про интерфейсы, а вот через неделю планирую взяться за главу ‘Deconstructing the REST myth’
Ну как «разработано». Операции «сдвинь элемент массива на n позиций влево» там нет, например. Если б любая предметная логика описывалась просто правкой JSON-ов, я бы давно помер с голода.
Ну и не могу не отметить, что поле, принимающее три значения — true, false и null — это какой-то кадавр, независимо от наличия в языке удобных конструкций для работы с такой псевдотроичной логикой.
API (как и контрактное программирование в целом) нужен в том числе для того, чтобы разработчики клиента были свободны в выборе технологий и не зависели от моих личный желаний и предпочтений.
Не очень понимаю, что вы этим хотели сказать.
Попробуйте взять другой генератор энтропии.
Согласно какому RFC, если не секрет?