Дмитрий Беляев

Тебе нужно подключение через ssh https://help.github.com/en/github/authenticating-t...

Finally гарантирует выполнение кода, независимо от того, была ошибка или нет.
А что будет, если код, обрабатывающий исключение, сам вбросит исключение?

try
{
  throw new ArgumentException();
}
catch(Exception)
{
      // any new exception thrown here
} 
CodeCleanup();

В данном случае выполнение логики прервется, соответственно, метод CodeCleanup не будет выполнен.

Подобное может случиться, например при вызовах методов, которые выполняют определенные сетевые операции, которые отваливаются по Timeout-у. В таком случае обычно делают N-ое кол-во повторных вызовов того же метода, чтобы исключить проблемы, связанные с настабильностью сети.

Finally решает эту проблему.

Интерфейс нужен не для того, что бы вы не забыли добавить какой-то метод. Он нужен, что бы вы работали, с контрактами. Например:

public function addToSwimmingPool(Swimming $animal): void
{
    $this->pool[] = $animal;
}

Так вы гарантируете, что добавите в бассейн только плавающих животных.

Без использования интерфейса, пришлось бы делать так:

public function addToSwimmingPool($animal): void { ... }

Тут вы могли добавить что угодно в массив. И потом где-нибудь программа бы сломалась, так как у переданных объектов нет нужных методов.

public function addToSwimmingPool(Penguin $animal): void { ... }

А так вы кроме пингвинов никого больше не добавите.

Интерфейс ГАРАНТИРУЕТ наличие такого метода в классе.

Порой, глядя на предыдущие ответы, я просто не понимаю - что творится в головах этих людей? Неужели все JS разработчики настолько забивают на производительность своих поделок?

function runTests() {
    const testCount = 1000;

    const testArrays = [];

    for (let i = 0; i < testCount; i++) {
        const arrayLength = Math.round(Math.random() * 100);
        const array = [];
        for (let i = 0; i < arrayLength; i++) {
            array.push(Math.random() * 10);
        }
        testArrays.push(array);
    }

    console.time('stringifyCompare');

    for (let i = 0; i < testCount - 1; i++) {
        compareStringify(testArrays[i], testArrays[i + 1]);
    }

    console.timeEnd('stringifyCompare');

    console.time('normalCompare');

    for (let i = 0; i < testCount - 1; i++) {
        compareTheRightWay(testArrays[i], testArrays[i + 1]);
    }

    console.timeEnd('normalCompare');
}

function compareStringify(first, second) {
    return JSON.stringify(first) == JSON.stringify(second);
}

function compareTheRightWay(first, second) {
    if (first.length != second.length) {
        return false;
    }

    for (let i = 0; i < first.length; i++) {
        if (first[i] != second[i]) {
            return false;
        }
    }

    return true;
}

runTests();

Результаты:
stringifyCompare: 21.304ms
normalCompare: 0.148ms

смешались люди и кони.

разрабы получают исходники и конфиг вебпака. запускают у себя вебпак и получают собранный код.

пхп и бд вебпак может и умеет, но нафига вообще представить не могу.

jsfiddle.net/831chb0g

Авторы надеялись, что к железу можно будет обращаться с помощью абстракций - производитель железа у себя реализует java-машину, а уж сверху нее можно запускать прикладной код.

Вы забываете о большом пласте истории техники, который был сильно до этого - 8 битные домашние ЭВМ (десятки их) и язык Бейсик.

Так вот, ЭВМ того времени были катастрофически разными - разные носители (кассеты, дискеты, картриджи), разная аппаратура (засунуть еще один центральный процессор в дисковод? да нивапрос! разная скорость для PAL и NTSC версий - легко!). Но вот бейсик был везде и позволял, с некоторыми переделками, таскать программы с машины на машину.

Таким образом, авторы находились в этом историческом контексте (у них все детство прошло в обнимку с каким-нибудь VIC-20). Тут уже становится логичным желание сотворить то же самое, только круче - берем современный язык, стандартизируем синтаксис - и делаем аналогично - производитель железа предоставляет нам Java-машину с нужным уровнем абстракции - и все программы бегают с архитектуры на архитектуру без переделок.

Отчасти, это сработало на старых мобилках, в эпоху j2me - это как раз Java, засунутая в телефон - игры, браузеры, карты (были даже ЯндексКарты), читалки, чатилки - куча всего.

Еще один виток эволюции, которые вы, видимо, не застали - (чорд, я - стар, я очень стар) - попытки сотворить интерактивные веб страницы.
"У нас же есть всюду переносимая Java - давайте влупим ее поддержку в браузер в виде апплетов - небольших приложений". Тут резко активировались вирусописатели и прочий сброд - благодаря развесистой и дырявой архитектуре, апплеты могли творить всякую дичь.

Сейчас апплет на java можно встретить во всяком старом железе, на нем там сделано GUI для удаленного администрирования серверов, коммутаторов и СХД. Вы браузером заходите на железку, и тут на вас вываливается ворох предупреждений о том, что сейчас будет запущено какое-то ужасное дырявое ПО, держите штаны, а то слетят. Уверены? Точно уверены? А с этим согласны? А так?

А уже потом начали активно применять JavaScript, главным образом, изобретя Ajax - продолжая люто натягивать сову (систему для создания электронных библиотек для ученых/HTML) на глобус (задачу создания интерактивного гуя с красивой версткой).

И это вы еще бэк на Perle не рефакторили

Почему вы считаете, что обращение по ключу - не поиск?

Ключ это прямой адрес в памяти?
Нет, а значит наверное надо выполнить поиск по всем объектам, чтобы найти нужный по ключу?
Нужно смотреть реализацию геттера, чтобы понять насколько там все сложно.

потребление энергии, если у тебя не крутится в памяти браузер с кучей джабоскриптованных по самое не балуйся вкладок или троянчег с майером поймал, без нагрузки должно быть минимальным. меньше лампочки в коридоре :) за полчаса не обеднеешь.
"Сон" компа сильно влияет на энергопотребление. ибо отключается все кроме обновления DRAM (hdd обычно тоже). так что можешь усыплять комп, но скоро надоест забьешь на такие мелочи.

Сама идея появилась от того, что при циклировании питания, изнашивается HDD и в гораздо меньшей степени, конденсаторы в цепях фильтрации питания.

Так что если исключить из рассмотрения HDD (его нет) и конденсаторы (там теперь кругом твердотельные), пробоем с циклированием нет никаких.

Идея о том, что частая гибернация может испортить SSD - также устарела, современные SSD и не такое переживут и будут заменены раньше - просто потому, что станут вмещать мало данных.

https://learn.javascript.ru/fetch-abort

https://gist.github.com/jexchan/2351996

https://gist.github.com/oanhnn/80a89405ab9023894df7