то есть по сути не существует способа безопасно пройтись по символам строки?

utf-8? существует - валидировать её сначала

а потом забожиться что оно не throwнется

utf-8? существует - валидировать её сначала

а потом всё равно засунуть в try-catch весь foreach

ну да, раз уж реализация такая

там в принципе решение предлагают

https://glot.io/snippets/ezydk7zsiz

а потом всё равно засунуть в try-catch весь foreach

а снаружи объявить nothrow

то есть по сути не существует способа безопасно пройтись по символам строки?

смотря что нужно, можно пропускать корявые utf-8 знаки, а можно бегать просто по массиву байт. Что именно нужно?

корявый utf-8 по сути своей исключительная ситуация для того что я делаю, nothrow не может быть в этой ситуации

ascii?

читаю из файла

ubyte[]?

тогда вообще вопрос стоять не должен

ну да

корявый utf-8 по сути своей исключительная ситуация для того что я делаю, nothrow не может быть в этой ситуации

не совсем понятно, у тебя там не utf-8 или utf-8, который гарантированно валидный?

не совсем понятно, у тебя там не utf-8 или utf-8, который гарантированно валидный?

не совсем понятно зачем мне это в nothrow =) у меня валидный utf-8, но без гарантии

ну тогда оно у тебя таки throwable

раз гарантий нет

ну вот я к этой мысли и пришёл)

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

а что за текст если не секрет?

а то может и правда оно ascii?

или например не имеет значения что там мусорные символы есть

а что за текст если не секрет?

строка с версией

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

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

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

тоже как вариант

ну или тупо try { foreach(... } catch(Exception e) { assert(0); }

ну или тупо try { foreach(... } catch(Exception e) { assert(0); }

Зависит от объёмов мусора. если его много то слишком частые эксепшены будут

там assert(0) стоит

предполагается, что невалидного utf-8 не может быть

да, надо просто игнорить, { }

Написать аналог питоновского unicode и забыть.

зачем его писать? все вроде уже ест в фобосе

например foreach(dchar ch; str.byDchar) можно делать в nothrow контексте

byDchar из std.utf

Да, что-то есть. Значит я недостаточно хорошо проникся сутью обсуждения.

Или из сути ускользнуло std.uni и иже с ними.

тампросто 10 челвоек онлине

6. Не стоит портирования :)

там важна система инвентаря. но я уже нашёл как она устроена, так что всё ок

Сорцы прочитал?)

там важна система инвентаря. но я уже нашёл как она устроена, так что всё ок

Я думаю что все структуры переделаю на camelCase, а то сейчас они 1в1 как в json и это некрасиво выглядит

Поясни? ВРоде хорошие названия

и документу телеграма соответствуют

сейчас они CamelCase

как я понял

сейчас они CamelCase

camelCase*

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

а с маленькой имена переменных

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

Имена типов - в PascalCase

ну вы понели

Вот фигней страдаю, что бы мне на D написать?

как я понял

Я вот про это https://github.com/nexor/telega/blob/master/source/telega/botapi.d#L156

Я вот про это https://github.com/nexor/telega/blob/master/source/telega/botapi.d#L156

вообще пофиг, как по мне. если документации самого телеграма соответствует так и ещё лучше

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

хм ну хз

Где-то camelCase а где то under_score, не очень хорошо смешивать так стили

Кодстайлы наше все

Где-то camelCase а где то under_score, не очень хорошо смешивать так стили

Вообще пофиг, воспринимается одинаково. Некоторые названия просто тем или иным способом субьективно хуже выглядят, и слепо идти по кодстайлу тут зло. Ну и соответствие телеграмовскому документу это удобно для grep

Когда пишется обёртка для api, лучше всего следовать стилям данного api насколько возможно, имхо. Тогда меньше придётся документировать уже задокументированное.

Я смотрю голанговское и тут все отмаплено в стандартный стиль https://github.com/go-telegram-bot-api/telegram-bot-api/blob/master/types.go#L97

Я смотрю голанговское и тут все отмаплено в стандартный стиль https://github.com/go-telegram-bot-api/telegram-bot-api/blob/master/types.go#L97

дык у них это в язык принудительно встроено

там private/public зависит от первой буквы имени переменной

они поехавшие там, да

там private/public зависит от первой буквы имени переменной

http://polit.ru/media/photolib/2014/12/08/thumbs/11_1418134930.png.600x450_q85.jpg

Как вам еще такая идея - https://github.com/nexor/telega/blob/master/source/telega/botapi.d#L269 я думаю эти методы вынести из класса и положить рядом. и в методы первым параметром добавить (BotApi botApi чтобы можно было через UFCS вызывать как и раньше, но при этом методы не являлись частью класса.

Как вам еще такая идея - https://github.com/nexor/telega/blob/master/source/telega/botapi.d#L269 я думаю эти методы вынести из класса и положить рядом. и в методы первым параметром добавить (BotApi botApi чтобы можно было через UFCS вызывать как и раньше, но при этом методы не являлись частью класса.

А смысл?

ERROR: S client not available

Просто методов будет дохрена

делай как тебе удобно - это же сахарок

много десятков

да и пускай, ничего страшного что дохрена

во щас найду пример

В dpq2 есть класс соединение и класс запрос

Ну как ничего страшного, это все влияет на восприятие библиотеки и навигации по коду

точнее, 2 файла

но класс это один фактически

куча методов разделена по смыслу на 2 файла таким образом: https://github.com/denizzzka/dpq2/blob/master/src/dpq2/query.d#L17

https://github.com/denizzzka/dpq2/blob/master/src/dpq2/connection.d#L79

Я думаю разделить на логические файлы

и всё, куча методов но на 2 файла разбросано по смыслу - одни отвечают за соединение, другие за запрос

inline.d, games.d, payments.d

basic.d - тут будут основные методы и сущности

скорее всего это всё как и в dpq2 должен быть 1 класс "соединение с телеграм"

Ну да

Но методов то будет куча

Как и классов методов. И сущностей

Все в одной куче держать не ок

имхо когда api реализуется не нужно думать об ООП

ну всмысле минимально нужно думать

если api явным образом не делится на классы, то стоит забить

в целевой программе всё равно это будет обёрнуто в нужные концепции

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

тогда это будет не телега, а карета

Например с UFCS методами кодер сможет добавлять свои методы в апи в таком же стиле, достаточно будет ему описать в своем файле Message someNewMethod(BotApi botApi, int param1)

имхо когда api реализуется не нужно думать об ООП

Тоже так думаю.

тогда уж класс (или стркутура) не BotApi а BotAccess или как-то так

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

Лучше в процесссе, в версии 2.0 что-то поменять если назреет

вспомниая dpq2 я раза 3 или 4 переделывал эти классы пока пришёл к тому что сейчас имеется

тогда уж класс (или стркутура) не BotApi а BotAccess или как-то так

BotConnection