Как стать автором
Обновить
0
0

Пользователь

Отправить сообщение
К. т. обработка ошибок во втором аргументе then практика не очень.

    somePromise.then(onResolve, onReject)

в этом случае, если ошибка возникнет в методе onResolve, то она не попадет в onReject
а в этом случае
    somePromise.then(onResolve).catch(onReject)

ошибка, которая может возникнуть в onResolve попадет в onReject

И немаловажный плюс — читабельность.
да, так правильнее
потому что там используются битовые операторы
В первом варианте получается
!((0 | 0) & 1) => !(0 & 1) => !(0) => true

а во втором
(!(0 | 0) & 1) => (!(0) & 1) => (1 & 1) => 1
FrozenInternet
>> Так что скорее всего, никак. А нужно ли?
Да не особо, просто ради интереса спросил.

TheShock
Да нет, я понимаю, что это то, что нужно вручную оптимизировать в последнюю очередь. Опять же спросил просто ради интереса.

Sirion
>> Можно даже высказать следующую еретическую мысль: чем больше разработчиков используют удобный для написания, но неэффективный способ сделать что-то, тем выше вероятность, что в новой версии движка этот способ будет оптимизирован)

Да, согласен.
Если я правильно понял статью то вот этот код
function Point(x, y) {
    this.x = x;
    this.y = y;
}
var p1 = new Point(1, 2);

инициирует создание трех скрытых классов
В то время как такой код:
var p1 = {x: 1, y:2 };

этого не сделает — будет только 1 скрытый класс.
Можно ли как-то в первом случае избежать создания лишних скрытых классов?
alpine или scratch все-равно лучше в продакшене. Например если на железном серваке крутится десяток (а то и больше) сервисов по несколько экземпляров.
Да, память относительно не дорога, но и расточительно ей пользоваться ИМХО не стоит.
Можно подробнее про «складывается с числом», «после чего можно декодировать всю строку» и «позицию 37»? Не совсем понятно, что с чем складывается, почему после преобразования буквы «u» можно декодировать всю строку и откуда взялось 37.

Предполагаю, что тут имелось ввиду, что если дальше продолжать увеличивать значение основания системы счисления, то при основании системе счисления 31+ все символы строки «null» будут являться цифрами системы счисления и parseInt(null, 31) вернет 714695. А 37 взсялось оттуда, что максимальное занчение основания системы счисления для parseInt является 36.

«складывается с числом»
ИМХО некоректный перевод
Оригинал:
It's converting null to the string «null» and trying to convert it. For radixes 0 through 23, there are no numerals it can convert, so it returns NaN. At 24, «n», the 14th letter, is added to the numeral system. At 31, «u», the 21st letter, is added and the entire string can be decoded. At 37 on there is no longer any valid numeral set that can be generated and NaN is returned.
почему столь важное событие, легитимность которого столь необходимо защитить, использует механизмы защиты многовековой давности? Особенно это странно, учитывая то, что схему для голосования, пусть и далеко не идеальную, но значительно лучшую, чем текущая, может придумать даже человек, разбирающийся в криптографии на начальном уровне.


Cui prodest
Из коробки — нет.
А вообще такая возможность есть https://docs.docker.com/engine/reference/commandline/stats/#formatting
https://habrahabr.ru/post/280099/
Можно сказать, что массив — это частный случай объекта.

https://www.ecma-international.org/ecma-262/#sec-array-objects

Ничто (кроме, пожалуй здравого смысла) не мешает сделать так:
   const obj = [];
   obj[0] = 0;
   obj[42] = 42;

Хм, а почему возвращается массив, в котором ключ — строка, а не целочисленный индекс?

выходит из того, что массив — частный случай объекта, а свойством объекта может быть только строка
Вы думаете, что компании с большими ресурсами не хотя что бы у разработчиков было 2 кнопки — «Реализовать фичу» и «Исправить все баги» что бы программисты работали/гребли в разы эффективнее?

Видимо не все так просто с IBM Watson, ИИ и т. п. в средствах разработки программного обеспечения. И IBM Watson, как и любой ИИ не способны решать широкий круг задач, а только то, под что они заточены.

Поэтому по сути чтобы создать универсальный человеческий язык препроцессор-интерпретатор-компилятор нужно всего лишь что-то типа IBM- Watson

Подумашеь, какая мелочь, надо каждому программисту поставить по суперкомпьютеру.
https://en.wikipedia.org/wiki/Watson_(computer)#Hardware
Долго писать не буду, а сразу скажу, что это без сомнений Glide.

Почему не Dep? Он хоть и сыр, но со временем обещают его внедрить в go tool

И что использовали для управления конфигами?
Мне надо было пакет, который умеет читать и мержить между собой несколько файлов конфигов, в зависимости от переменной окружения. Не нашел такого в свое время…
Объясните, пожалуйста, следующее.

Из прочитанного я сделал следующий вывод.
Вирус работает в 2 этапа:
— на первом этапе заменяется MBR
— на втором шифруются данные в разделах.

Если я все правильно понял, то вопрос в следующем — на свежих ПК и ОС в основном, если не ошибаюсь используется GPT разметка — подвержены ли риску такие ПК?
Спасибо, я так понял речь об этом https://golang.org/cmd/compile/#hdr-Compiler_Directives
SirEdvin
Вместо комментариев там метаинформация, доверять которой нельзя, так как никто не знает, не приймет ли ее за инструкции библиотека, которую вы подключите.


Можете объяснить что вы имеете ввиду? Потому что согласно спецификации языка комментарии таки есть — https://golang.org/ref/spec#Comments

P.S. Промахнулся…
есть пакет https://godoc.org/github.com/facebookgo/inject

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность