AM
И вообще, почему обязательно бородачи иранцы да индусы, где горячие вьетнамки, которые тоже хотят познакомиться?
Я думаю, сидят в вичате и жалуются друг другу, что эти бородачи иранцы да индусы задолбали со своими дикпиками.
Size: a a a
2020 November 25
AD
Но то с аниме чатов
ящитаю, нужен еще один заход, где ты представишься девушкой
U
Не последний индус, я полагаю. Надо будет попробовать.
I
оно не вычисляет точки по 2 раза и более понятные функции
А зачем? Один персонаж тут (хотя уже нет его тут) утверждал же, что компилятор всё соптимизирует?
с#
А зачем? Один персонаж тут (хотя уже нет его тут) утверждал же, что компилятор всё соптимизирует?
это шутка или реально пофиг?
с#
наверное шутка
I
это шутка или реально пофиг?
Мне почему-то кажется, что в таком простом случае он прав. Даже если компилятор не соптимизирует, из-за ленивости в первый раз thunk заменится значением, а во второй раз уже будет браться вычисленное значение. Но надо смотреть.
с#
ну может быть
d
Не помню таких сентенций от скобки
AM
AM
И это я не старался
с#
так хочу уже SealedInterface, чтобы писать такие штуки.
class TokenError : AuthError, GetMessageError, SendMessageError {
...
}
fun auth(...): AuthError
class TokenError : AuthError, GetMessageError, SendMessageError {
...
}
fun auth(...): AuthError
с#
я конечно и щас могу это делать, но хочется exhaustive-условия
I
так хочу уже SealedInterface, чтобы писать такие штуки.
class TokenError : AuthError, GetMessageError, SendMessageError {
...
}
fun auth(...): AuthError
class TokenError : AuthError, GetMessageError, SendMessageError {
...
}
fun auth(...): AuthError
А где тут интерфейс?
с#
А где тут интерфейс?
AuthError, GetMessageError, SendMessageError
с#
типо чтобы ошибки результат был sealed
I
AuthError, GetMessageError, SendMessageError
И они все sealed
с#
и если ошибка может быть возвращена в методе auth, то её надо пометить sealed интерфейсом AuthError
a
Всем привет, вопрос в архитектуре микросервисов. Возможно не туда. Поправьте если так. Есть три задачи:
1) Аутентификация и выдача токенов.
2) Восстановление пароля, путем отправки проверочного кода смс и его верификации
3) Регистрация пользователя
По сути всем трем сервисам необходимо так или иначе заглядывать в одну БД с таблицей Accounts...
Первый сервис проверяет истинный логин и пароль
Второй - меняет пароль
Третий - добавляет новую запись.
Как же быть, если микросервисы должны быть изолированны друг от друга? Или же допустимо использовать одну БД
1) Аутентификация и выдача токенов.
2) Восстановление пароля, путем отправки проверочного кода смс и его верификации
3) Регистрация пользователя
По сути всем трем сервисам необходимо так или иначе заглядывать в одну БД с таблицей Accounts...
Первый сервис проверяет истинный логин и пароль
Второй - меняет пароль
Третий - добавляет новую запись.
Как же быть, если микросервисы должны быть изолированны друг от друга? Или же допустимо использовать одну БД