Ну, приведенный в комментарии код можно записать и как генератор — при помощи вот этого, например. В таком случае `await` будет `yield`, а больше ничего не изменится.
А сам boot.js — это что-то типа такого. Надо будет повыбрасывать оттуда кучу трансформаций, т.к. их уже node давно поддерживает нативно, типа тех же классов. В таком случае, строку запуска можно поменять на что-то типа этого:
Признаться, я пользуюсь Mocha, и с ней никаких проблем не было — запуск тестов ничем не отличается от планового запуска кода, дополнительных телодвижений для этого не нужно. Для karma, как я погуглил, есть варианты:
1) использовать --require boot.js, как в примере выше, тогда все будет «просто работать»
2) использовать штуки типа github.com/babel/karma-babel-preprocessor
в мире до сих пор полно проектов
Есть уважительная причина — legacy. Для новых проектов нет причин, почему не использовать ES2015/ES2016.
А вы, как автор, видите какие-то (пусть даже граничные) сценарии атаки на подобную схему? Что должно пойти не так (кроме хренового генератора случайных чисел на стороне отправителя), чтобы все стало плохо?
Возможно, но что плохого в транспилировании? Речь ведь не о языках типа CoffeeScript или LiveScript, которые должны поддерживаться, и если поддержка прекратится, то все, приехали. Транспиляция идет из фактически будущей версии языка, которую рано или поздно будет поддерживать платформа, и от транспиляции этих функций можно будет отказаться.
Выполнение генератора линейно, как и выполнение функции, но ничто не мешает вам оставаться в нужном состоянии сколько угодно долго, используя циклы:
async function shell(password) {
await write('What is the password?');
while (true) {
const guess = await read();
if (guess === correctPassword) {
await write('Nice guess!');
break;
}
await write('Nope! ;)');
}
while (true) {
await write('Okay, now enter some secret command');
const command = await read();
switch (command) {
case 'secret': {
await write('Purrrfect!');
break;
}
case 'bye': {
await write('Okay, see you later');
return;
}
}
}
}
Естественно, это все можно описать при помощи конечного автомата, потому что это и есть конечный автомат в конечном итоге — но такая запись, как мне кажется, немного человекочитаемее.
А, позвольте уточнить, почему не использовать генераторы (function* foo() {}) или копроцедуры (async function foo() {})? Они позволяют описывать конечные автоматы неявно, кратко, и не заботясь о вынесении состояния «за скобки».
sergku1213olartamonov Если написанное в статье чушь, то как понимать эту цитату из их публикации?
By quenching the carbon from the super undercooled state, we have created a new state of carbon (Q-carbon) [...] The Q-carbon quenched from liquid is a new state of solid carbon with a higher mass density than amorphous carbon and a mixture of mostly four-fold sp3 (75-85%) and the rest three-fold sp2 bonded carbon (with distinct entropy). It is expected to have new and improved mechanical hardness, electrical conductivity, chemical and physical properties, including room-temperature ferromagnetism (RTFM) and enhanced field emission. Here we present interesting results on RTFM, enhanced electrical conductivity, and surface potential of Q-carbon to emphasize its unique properties. The Q-carbon exhibits robust bulk ferromagnetism with estimated Curie temperature of about 500K and saturation magnetization value of 20 emu/g.
Это абсолютно неубедительное и, увы, совершенно не доказательство. То, что библиотека выдает те же значения не означает, что в ней нет уязвимостей — например, что шифрование и дешифрование выполняется всегда за одно и то же время для любых комбинаций ключей и открытого текста. Или что вызов garbage collector-а не является причиной наблюдаемых задержек для определенных комбинаций данных. Или что Math.floor(65536 * Math.random()) — это не самая лучшая реализация CSPRNG. Даже если это потом скормить RC4, это все равно адский шлак.
Это в случае ошибок в самом транспайлере? Нельзя исключать, конечно. А при использовании транспайленного кода sourcemaps это обрабатывают.
Чего именно, внедрения транспайлера? Тот же babel подключается, например, следующим образом:А сам boot.js — это что-то типа такого. Надо будет повыбрасывать оттуда кучу трансформаций, т.к. их уже node давно поддерживает нативно, типа тех же классов. В таком случае, строку запуска можно поменять на что-то типа этого:
Признаться, я пользуюсь Mocha, и с ней никаких проблем не было — запуск тестов ничем не отличается от планового запуска кода, дополнительных телодвижений для этого не нужно. Для karma, как я погуглил, есть варианты:
1) использовать
--require boot.js, как в примере выше, тогда все будет «просто работать»2) использовать штуки типа github.com/babel/karma-babel-preprocessor
Есть уважительная причина — legacy. Для новых проектов нет причин, почему не использовать ES2015/ES2016.
Естественно, это все можно описать при помощи конечного автомата, потому что это и есть конечный автомат в конечном итоге — но такая запись, как мне кажется, немного человекочитаемее.
function* foo() {}) или копроцедуры (async function foo() {})? Они позволяют описывать конечные автоматы неявно, кратко, и не заботясь о вынесении состояния «за скобки».Откуда берется ферромагнетизм?
Math.floor(65536 * Math.random())— это не самая лучшая реализация CSPRNG. Даже если это потом скормить RC4, это все равно адский шлак.Math.floor(65536 * Math.random())Кхм… Я думаю, эту реализацию CSPRNG можно закапывать.