Сначала подумал, что автор статьи под polling имеет ввиду long polling, но нет, в статье описывается именно обычный polling и его недостатки, тогда как телеграм использует именно long polling. Отсюда делаю вывод, что автор не вникал в предмет статьи и/или вовсе написал статью используя нейросеть
Тоже такой вариант сразу на ум пришёл. На мой вкус, это явно лучше атрибута со строковым ключом, который разработчику придётся брать непонятно откуда.
А вот явное внедрение реализации вместо интерфейса, чревато тем, что тестировать код станет сложнее. Если в некоторых языках ещё можно mock'ать классы, то, насколько знаю, в NET это сделать невозможно.
Интересно, если бы кандидат в качестве ответа на данный вопрос написал такую регулярку: @, то его бы попросили вон или сразу бы сделали сеньором-помидором?
Ну к примеру про ошибки формата Copy-Paste не подсказывает, ну это в принципе было логично
Не совсем. По какой-то странной причине, IDEA не обнаруживает подобные ошибки при сравнении через ==, но ругается при использовании Objects.equals(obj, obj) или `obj.equals(obj)
Понятно, что в стандартной библиотеки нужно использовать самые оптимальные по памяти и скорости алгоритмы, идти на любые ухищрения, лишь бы всё работало быстро и эффективно. Но читать код всех этих стейтмашин, от этого проще не становится.
Смотрю я на все эти ухищрения, для того, чтобы итераторы нормально работали и меня охватывает тоска. Вот поддерживала бы jvm генераторы или разработчики kotlin реализовали бы их сами на уровне генерации байткода(не знаю, насколько это реализуемо, но компилятор C# именно так и делает), столько лишней работы можно было бы избежать. Например, реализация flatten стала бы настолько простой, что даже как-то смешно.
fun <T> Iterable<Iterable<T>>.flatten(): Iterable<T>{
for(iterable in this){
for(item in iterable){
yield item
}
}
}
И производительность при этом проседать не должна, так как по сути при генерации получился бы такой же код, как и в ручной реализации, а при наличии поддержки yield со стороны JVM, ещё бы и прибавку в скорости могли получить.
Спасибо! Ваши советы помогли мне наконец отрефакторить мой код должным образом.
Чистый код, как он есть
# в этом файле мы считываем пользовательский ввод и складываем числа
chislo = 0
# складываем числа введённые пользователем используя встроенный оператор сложения +
# цикл помогает нам сэкономить количество строк
for vyrazhenie in ['input("Введите число 1")', 'input("Введите число 2")', 'input("Введите число 3")', 'input("Введите число 4")', 'input("Введите число 5")', 'input("Введите число 6")', 'input("Введите число 7")', 'input("Введите число 8")']:
import matematika
chislo = matematika.plus(chislo, eval(vyrazhenie))
# заменяем числа на буквы если возможно для крутости
# если вдруг понадобится вывести число в одну строку, то тот кто вызывывает код может перехватить вывод и сделать всё как надо!
for zyfra in str(chislo):
if zyfra == '0':
print('O')
elif zyfra == '1':
print('l')
elif zyfra == '3':
print('')
elif zyfra == '4':
print('Ч')
elif zyfra == '6':
print('Б')
elif zyfra == '8':
print('B')
elif zyfra == '9':
print('Я')
else:
print(zyfra+'(NOT COOL)')
Не очень красиво, перепрыгивать с вычисления площади, до расчёта баланса. Само собой, при расчёте баланса нужно будет учитывать и возможность деления на ноль, и все варианты выхода за пределы диапазона int. Это не ответственность Bindings.multiply, $derived и, скорее всего, UI в целом. Да и о каком переполнении в контексте баланса может идти речь, когда при любых важных расчётах с деньгами, необходимо использовать BigInteger/BigDecimal.
С 8 версии есть нормальное сложение. Разве? Это включается каким-то флагом или как? По умолчанию, будет переполнение.
Вы считаете 0 при исключениях адекватным поведением? Конкретно в случае с сахаром в виде Bindings.multiply/Bindings.divide, я считаю такое поведение оправданным. Если хочется самому обработать ошибку, то пожалуйста, есть Bindings.createIntegerBinding или его более низкоуровневый аналог IntegerBinding.
var width = new SimpleIntegerProperty();
var height = new SimpleIntegerProperty();
var area = Bindings.createIntegerBinding(
() -> {
try{
return width.get() / height.get();
}
catch (ArithmeticException e){
return ohNoTheHeightIsZero(width.get());
}
},
width, height // зависимости
);
var area = new IntegerBinding(){
{
bind(width, height); // зависимости
}
@Override
protected int computeValue() {
try{
return width.get() / height.get();
}
catch (ArithmeticException e){
return 42;
}
}
};
И на всякий случай скажу, что мой первый комментарий был сарказмом. Там даже плашечка в конце стоит. Само собой, я не считаю JavaFX верхом развития реактивного программирования.
ArithmeticException при переполнении не будет, это же Java. При любом другом исключении, Binding залогирует исключение и примет значение 0. Это же значение и будет передано в слушатель третьим параметром(newValue).
В newValue придёт произведение примитивов, которые обёрнуты в SimpleIntegerProperty. Как эти примитивы перемножаются, что будет при переполнении, за это отвечает Java(или, скорее, JVM).
Ничтожества. Столько лет вам понабилось на то, чтобы прийти к модели свойств JavaFX.
var width = new SimpleIntegerProperty();
var height = new SimpleIntegerProperty();
var area = Bindings.multiply(width, height);
area.addListener((observable, oldValue, newValue) -> {
System.out.println(newValue);
});
Действительно. Сначала хотел написать, мол это babel такой плохой, но прочитав это issue понял, что:
PEP 498 completely ignores localization as if you never need to use localized programs with string interpolation.
Интересно, в других языках дела с переводами интерполируемых строк обстоят также или есть какое-то решение, которое разработчики питона почему-то проигнорировали.
Раньше такие срачи имели место быть, но после появления f-строк есть резон использовать другие варианты? Минусов у f-строк не много. Например, они не подходят для динамического форматирования(с заранее неизвестным форматом строки и, возможно, набором переменных), но это редкий случай использования(само собой, речь идёт о простых строках, где jinja это слишком). И нельзя отметить, что автодополнение и подсветка ошибок вашей среды разработки, будет прекрасно работать для f-строк.
Все бы так игры "забрасывали" и глядишь — коммунизм бы наступил
Сначала подумал, что автор статьи под polling имеет ввиду long polling, но нет, в статье описывается именно обычный polling и его недостатки, тогда как телеграм использует именно long polling.
Отсюда делаю вывод, что автор не вникал в предмет статьи и/или вовсе написал статью используя нейросеть
Тоже такой вариант сразу на ум пришёл. На мой вкус, это явно лучше атрибута со строковым ключом, который разработчику придётся брать непонятно откуда.
А вот явное внедрение реализации вместо интерфейса, чревато тем, что тестировать код станет сложнее. Если в некоторых языках ещё можно mock'ать классы, то, насколько знаю, в NET это сделать невозможно.
Почему, а главное зачем?
В этом есть какой-то практический смысл?
Интересно, если бы кандидат в качестве ответа на данный вопрос написал такую регулярку:
@, то его бы попросили вон или сразу бы сделали сеньором-помидором?Не совсем. По какой-то странной причине, IDEA не обнаруживает подобные ошибки при сравнении через ==, но ругается при использовании
Objects.equals(obj, obj)или `obj.equals(obj)Зачем ждать релиза Mojo, когда Cython уже существует?
Автор статьи тоже не дурак и в самом начале кода прописал
from __future__ import annotations, что включает Postponed Evaluation of AnnotationsПонятно, что в стандартной библиотеки нужно использовать самые оптимальные по памяти и скорости алгоритмы, идти на любые ухищрения, лишь бы всё работало быстро и эффективно. Но читать код всех этих стейтмашин, от этого проще не становится.
Смотрю я на все эти ухищрения, для того, чтобы итераторы нормально работали и меня охватывает тоска. Вот поддерживала бы jvm генераторы или разработчики kotlin реализовали бы их сами на уровне генерации байткода(не знаю, насколько это реализуемо, но компилятор C# именно так и делает), столько лишней работы можно было бы избежать. Например, реализация flatten стала бы настолько простой, что даже как-то смешно.
И производительность при этом проседать не должна, так как по сути при генерации получился бы такой же код, как и в ручной реализации, а при наличии поддержки yield со стороны JVM, ещё бы и прибавку в скорости могли получить.
Спасибо! Ваши советы помогли мне наконец отрефакторить мой код должным образом.
Чистый код, как он есть
Не очень красиво, перепрыгивать с вычисления площади, до расчёта баланса.
Само собой, при расчёте баланса нужно будет учитывать и возможность деления на ноль, и все варианты выхода за пределы диапазона int. Это не ответственность Bindings.multiply, $derived и, скорее всего, UI в целом.
Да и о каком переполнении в контексте баланса может идти речь, когда при любых важных расчётах с деньгами, необходимо использовать BigInteger/BigDecimal.
И на всякий случай скажу, что мой первый комментарий был сарказмом. Там даже плашечка в конце стоит. Само собой, я не считаю JavaFX верхом развития реактивного программирования.
ArithmeticException при переполнении не будет, это же Java. При любом другом исключении, Binding залогирует исключение и примет значение 0. Это же значение и будет передано в слушатель третьим параметром(newValue).
В newValue придёт произведение примитивов, которые обёрнуты в SimpleIntegerProperty. Как эти примитивы перемножаются, что будет при переполнении, за это отвечает Java(или, скорее, JVM).
Ничтожества. Столько лет вам понабилось на то, чтобы прийти к модели свойств JavaFX.
/s
Было бы у человека 12 пальцев, была бы двенадцатеричная система.
Было бы у человека 60 пальцев, была бы шестидесятеричная система.
Действительно. Сначала хотел написать, мол это babel такой плохой, но прочитав это issue понял, что:
Интересно, в других языках дела с переводами интерполируемых строк обстоят также или есть какое-то решение, которое разработчики питона почему-то проигнорировали.
Раньше такие срачи имели место быть, но после появления f-строк есть резон использовать другие варианты?
Минусов у f-строк не много. Например, они не подходят для динамического форматирования(с заранее неизвестным форматом строки и, возможно, набором переменных), но это редкий случай использования(само собой, речь идёт о простых строках, где jinja это слишком).
И нельзя отметить, что автодополнение и подсветка ошибок вашей среды разработки, будет прекрасно работать для f-строк.
f-строки и есть тот самый obvious way. Конкуренты проигрывают по всем возможным пунктам настолько, что не использовать f-строки глупо.