Магазин-то что ощутит? Разгневанную очередь, громящую кассу? Пять минут ожидания — не такая и большая потеря в прибыли (а если потеря будет заметной — её найдут на кого повесить).
Ну как сказать… В основе может лежать сколь угодно производительная библиотека, но если поверх неё навалить кучу «бутылочных горлышек» (я сейчас не про авторов игры, а про сам phaser), то получится… кхм… как у упомянутого RPG Maker версии MV (который тоже на pixi.js + nw.js основан).
Баловался в своё время с RPG Maker-ом разных версий (сейчас немного подзабросил, правда), в том числе и с нырянием в код, так что статью не мог не оценить, спасибо!
Насчёт английского да, можно было добавить. Но неужели таких много?!
Закончил мехмат, сейчас в аспирантуре. Английский у нас, конечно, был, но сложно сказать, что я его сколько-нибудь изучил именно в стенах вуза — занятия были, по моим ощущениям, довольно слабые, самое лучшее в них — попытка упора на разговорную практику (брать пример с героев Тарантино, без шуток). Нынешнее отличие моих знаний от «London is the capital of Great Britain» — по большей части заслуга музыки (хочется же понимать, что там поют эти чёртовы Depeche Mode и иже с ними) и документации/статей/обсуждений по уже непосредственно задачам программирования (плюс немного от статей по темам курсовой/дипломной). Можно сказать — «учил самостоятельно»? Пожалуй, да. Типичный случай (хотя бы и для доли процента респондентов)? Не факт, но возможно.
Вопрос, насколько я понимаю, с подвохом, поскольку официально в JS int отсутствует вообще, и надо знать, при каких условиях он всё-таки существует, помимо всего прочего?
Очень хороший пример. :) Исключение из правил при сравнении. И в реальной жизни, как мне кажется, малоприменимый случай.
Я ведь правильно понимаю, что это аналог (примерный) строгого и нестрогого сравнения в JS, где активно рекомендуется использовать строгое везде где только можно, чтобы не делать лишних приведений типов?
С другой стороны, переходить с чего-то статически типизированного (хотя бы и с TypeScript, чем чёрт не шутит) на "динамику" — это тоже иногда боль, особенно если привыкнуть к хорошей поддержке со стороны IDE (да хотя бы и тот же VS Code для уже упомянутого TS). Хотя, конечно, я мог слишком быстро сдаться, и вообще давно пора RubyMine пощупать...
3. Банально: ситуации, когда присваивание переменной должно происходить в блоке (try, например), а чтение — после него (допустим, что в catch мы всегда выходим из функции, соответственно, после try/catch значение в переменную записано успешно). Примерно так:
function () {
let variable
try {
variable = someFunc()
} catch(e) {
throw new Error('someFunc errored: ' + e.message)
}
return someLongProcedure(variable)
}
В этом случае, если переместить let variable внутрь блока try, переменная будет недоступна для someLongProcedure.
4. Конкретно в Вашем примере есть одно возражение — общая vs множественная точка выхода. Неоднократно встречал утверждение, что второе — антипаттерн, поскольку усложняет, к примеру, добавление операций перед выходом (скажем, если требуется логировать возвращаемое значение). Хотя с общим посылом, пожалуй, согласен.
1. Припоминаю, что у меня был практический случай, заставляющий относиться к такому приёму с недоверием. Не помню уже детали, то ли это был массив объектов, который криво обрезался, то ли что…
3. Я ведь правильно понимаю, что это работает только при инициализации переменной, а значит — не всегда дружит с let?
4. Вот это для меня новость, хоть и не могу с ходу придумать вменяемый случай, где это уместно.
7. Интересно, есть ли хоть один человек, который работал с JSON.stringify и не знает этой возможности?..
В общем, статья, конечно, интересная, и мне, как разработчику, прямо скажем, не слишком ещё пока высокого уровня, даже полезная, но — именно с поправкой на уровень. Так-то конечно, спасибо, и автору, и переводчику.
… которое, опять же, разбивается за один проход отладчика. Который нужен, по Вашим же собственным словам, и в первом случае, если по каким-то причинам оказалось неясно, какая именно из веток в данных условиях отрабатывает. Я не спорю с тезисом (что код с if-elseif выглядит читабельнее), я пытаюсь понять обоснованность аргумента.
Честно говоря, не очень понял аргумент с точкой останова. Ясно же, что и в случае с return-ами вариант «встать на первое условие внутри функции и проследить выполнение до момента выхода» тоже сработает. А если функция такая громоздкая, что проходить её пошагово сначала — нерациональная трата времени, так и в случае с цепочкой elseif-ов результат будет ровно такой же (не говоря уж о вопросе, рационально ли её делать в этом случае одной функцией).
Тот неловкий момент, когда за последний месяц делал три разных тестовых задания (на C#, PHP и JS соответственно) в три разных фирмы, поскольку ещё не определился с тем, каким именно джуном хочешь быть… Нет, в перспективе-то можно и такой подход на вооружение взять, но сейчас момент именно что неловкий.
Прямо интересно стало, что за приведение типов происходит в первом случае...
Баловался в своё время с RPG Maker-ом разных версий (сейчас немного подзабросил, правда), в том числе и с нырянием в код, так что статью не мог не оценить, спасибо!
Закончил мехмат, сейчас в аспирантуре. Английский у нас, конечно, был, но сложно сказать, что я его сколько-нибудь изучил именно в стенах вуза — занятия были, по моим ощущениям, довольно слабые, самое лучшее в них — попытка упора на разговорную практику (брать пример с героев Тарантино, без шуток). Нынешнее отличие моих знаний от «London is the capital of Great Britain» — по большей части заслуга музыки (хочется же понимать, что там поют эти чёртовы Depeche Mode и иже с ними) и документации/статей/обсуждений по уже непосредственно задачам программирования (плюс немного от статей по темам курсовой/дипломной). Можно сказать — «учил самостоятельно»? Пожалуй, да. Типичный случай (хотя бы и для доли процента респондентов)? Не факт, но возможно.
Я ведь правильно понимаю, что это аналог (примерный) строгого и нестрогого сравнения в JS, где активно рекомендуется использовать строгое везде где только можно, чтобы не делать лишних приведений типов?
С другой стороны, переходить с чего-то статически типизированного (хотя бы и с TypeScript, чем чёрт не шутит) на "динамику" — это тоже иногда боль, особенно если привыкнуть к хорошей поддержке со стороны IDE (да хотя бы и тот же VS Code для уже упомянутого TS). Хотя, конечно, я мог слишком быстро сдаться, и вообще давно пора RubyMine пощупать...
В этом случае, если переместить let variable внутрь блока try, переменная будет недоступна для someLongProcedure.
4. Конкретно в Вашем примере есть одно возражение — общая vs множественная точка выхода. Неоднократно встречал утверждение, что второе — антипаттерн, поскольку усложняет, к примеру, добавление операций перед выходом (скажем, если требуется логировать возвращаемое значение). Хотя с общим посылом, пожалуй, согласен.
3. Я ведь правильно понимаю, что это работает только при инициализации переменной, а значит — не всегда дружит с let?
4. Вот это для меня новость, хоть и не могу с ходу придумать вменяемый случай, где это уместно.
7. Интересно, есть ли хоть один человек, который работал с JSON.stringify и не знает этой возможности?..
В общем, статья, конечно, интересная, и мне, как разработчику, прямо скажем, не слишком ещё пока высокого уровня, даже полезная, но — именно с поправкой на уровень. Так-то конечно, спасибо, и автору, и переводчику.