Неожиданный порядок инициализации наследованных классов в JavaScript

Просто ненадо выполнять код в конструкторе

class BaseTooltip {
    template = 'baseTemplate'
    constructor(options) {
         this.options = options
    }
    render(content) {
        console.log('render:', content, this.template, this.options)
    }
}

const tooltip = new BaseTooltip(options)
tooltip.render('content')

Реализация сопоставления с образцом в Java

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

Сопоставление с образцом используется в функциональных языках, потому что в них нет понятия инкапсуляции и типов (в том понимании в котором они используются в Java например).
В Java да, именно что под каждый промежуточный вариант надо делать свой класс. Так принято в Java. Но ненадо в Java тащить чужеродные концепции. Если не умеете программировать на Java, и очень хочется использовать pattern matching — идите в Haskel, Lisp, Scala и т.п.

Реализация сопоставления с образцом в Java

примеры из статьи — искуственные и показывают что можно делать (но отнюдь не что нужно).

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

switch (side, width) {
      case "top",    25 -> System.out.println("top");
      case "bottom", 30 -> System.out.println("bottom");
      case "left",   15 -> System.out.println("left");        
      case "right",  15 -> System.out.println("right"); 
      case null         -> System.out.println("Null value ");
      default           -> System.out.println("Default value ");
};

Реализация сопоставления с образцом в Java

Совершенно независимо от качества примеров автора (и ограниченности данной библиотеки), вы похоже не понимаете, что такое pattern matching, и зачем он нужен.

Я прекрасно понимаю что это за паттерн и зачем он нужен. И что он принципиально не совместим с Java.

Не было бы. Представьте на мгновение, что figure — это не ваши классы, что они написаны сторонним разработчиком, и менять (а то и посмотреть на их код) вы не можете.

В этом случае тем более никак и никогда не могу использовать паттерн матчинг, потому что все что я вижу из библиотеки — это интерфейсы. я не вижу внутренностей объектов. Попытка использовать тяжелую артиллерию вроде рефлекшена для того чтобы подсмотреть внутренности объектов в библиотеке — это ядерная бомба замедленного действия. В следующей версии библиотеки автор поменяет свои объекты, и весь паттерн матчинг рухнет как карточный домик.
Если я хочу что-то добавить к коду библиотеки, я оборачиваю библиотечные классы своими классами, но никак не лезу рефлекшеном внутрь библиотечных классов.
Вы просто не понимаете суть ООП, если для вас добавление чего-то к библиотечному коду это обязательно означает разобрать объект на кусочки.

Реализация сопоставления с образцом в Java

Вообще-то нет, не сочетается, причем совсем. Вот рассмотрим «чудесный» паттерн декоструктор из статьи

switch (figure) {
      case Rectangle(int w, int h) -> out.println("square: " + (w * h));
      case Circle(int r)        -> out.println("square: " + (2 * Math.PI * r));
      default                      -> out.println("Default square: " + 0);
};

В ООП это было бы

out.println(String.format("square: %f", figure.square()));

или

figure.printSquare();

Но никак не так как в примерах из статьи. Тоесть, либо одно, либо другое, вместе никак.
Ну а если в программе возникает необходимость писать подобный код

switch (data) {
      case Integer i  -> System.out.println(i * i);
      case Byte    b  -> System.out.println(b * b);
      case Long    l  -> System.out.println(l * l);        
      case String  s  -> System.out.println(s * s);
      case null       -> System.out.println("Null value ");
      default         -> System.out.println("Default value: " + data);
};

это значит лишь то что объектно-ориентированный дизайн зашел куда-то совсем не туда. Ну или это код внутри самой JDK, что врядли.

Реализация сопоставления с образцом в Java

PHP просто как пример того как бездумное добавление новых возможностей в язык в итоге превращает его в непонятно что. Место PHP в этом примере легко займут и JavaScript, и Kotlin

Реализация сопоставления с образцом в Java

Pattern matching — функциональщина, притащенная «во многие языки» без понимания принципов, просто для того чтобы была лишняя фича, в рамках «развития языка». Притащенная соответственно функциональщиками, людьми, которые не знают что такое инкапсуляция.

Печально смотреть, как Java, хороший язык, со стройными изначально принципами ООП, все больше и больше превращают в PHP. Даже термин специальный придумали — деконструкция, ужас какой.

Что представила Apple на WWDC, и что об этом думают iOS-разработчики

Очень удобные и полезные функции делает Apple для пользователей. Только вот теперь получается что сама Apple может отслеживать пользовательские устройства даже в выключенном состоянии.

Консенсус — ложь

Вот именно потому что люди устанавливают правила, у машин нет шансов договориться о чем-то с людьми, т.к. машины на правила не влияют. Машины могут только договориться между собой.

Консенсус — ложь

договоренность машин и людей о чём либо по установленным правилам

Консенсус — это договоренность машин с машинами по установленным правилам. Люди с машинами ни о чем не договариваются, люди смотрят на результат договоренности машин между собой, и принимают решения на его основе.

Консенсус — ложь

Родительский-то как раз Classic, ибо там остались прежние правила работы сети на тот момент, а ETH это дочерняя цепь, её специально скопировали чтобы изменить правила под конкретную задачу. НУ просто название ETH с собой забрали.

В PHP 7.4 войдут стрелочные функции (сокращенная запись анонимных функций)

Так вот и я про тоже, зачем усложнять когда можно упростить. И вообще примеры надо приводить подчеркивающие нужность концепции, а не опровергающие её. только вот есть ли они, эти примеры?

В PHP 7.4 войдут стрелочные функции (сокращенная запись анонимных функций)

$result = Collection::from([1, 2])
    ->map(fn($v) => $v * 2)
    ->reduce(fn($tmp, $v) => $tmp + $v, 0);

И чем это лучше чем

$result = 0;
for ($v = 1; $v < 3; $v++)
    $result += $v * 2;

Вообще ничем, лишние слова map, reduce, Collection, fn, лишний синтаксис, fn, =>, и компактнее код совсем не стал. Нафига козе боян. Простой и понятный язык превращают непонятно во что, только потому что модно, и в других языках есть.

Не в силах объяснить монаду

1, 2. Вы просто как, видимо, функциональщик, акцентируете внимание на действиях, «щипать» и «бросать». НУ в этом смысле да, если «не замечать» объекты, то как бы их и нет :) есть только «функции».

Не в силах объяснить монаду

Лужа с камнем никуда не делись, камень изменил свои координаты и теперь лежит в луже. Просто Ваше внимание переключилось с лужи и камня на волну, которая возникла на поверхности лужи, для описания формы которой Вы читаете Бэтчелора, Тихонова+Самарского и составляете систему уравнений Навье-Стокса.

Не в силах объяснить монаду

А я как раз про то что в большинстве задач ООП рулит, потому что большинство задач не про то как красиво вычислить числа фибоначи, или очень круто параллельно умножить каждый элемент массива на 2. Большинство задач про то как провести платеж пользователя, передать сообщение в чат, сохранить файл на диск, показать видео в окошке. И в них всех гораздо лучше подходит ООП.

Не в силах объяснить монаду

Насчет ФП как способа выражения своих мыслей — ну это хорошее замечание, хотя вам уже пару раз ответили, что никто не проектирует системы в терминах аппликативных функторов. Кстати, я сильно сомневаюсь, что вы сможете также адекватно спроектировать систему в терминах ООП для любого произвольного применения.

Для любого произвольного и не надо, системы проектируются под конкретную клиентскую задачу. Система для любого произвольного применения — ОС. Только надо сначала программу написать :) а так любую задачу решает.

Не бывает абстрактных задач, все задачи конкретные.

Почему города сопротивляются внедрению Amazon Go, первых магазинов без касс

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

Почему города сопротивляются внедрению Amazon Go, первых магазинов без касс

Несомненно. Зато хакер может своровать деньги сразу у 1000 человек, чего гопник не может.

Ясное дело, вероятность быть ограбленным на улице повыше, чем в банке, и таскать с собой килограммы наличности постоянно не самая лучшая идея. Но и банк не дает 100% защиты, везде свои риски.

Почему города сопротивляются внедрению Amazon Go, первых магазинов без касс

Ну надо сказать на улице меня тоже не грабили никогда. Били, было дело. Карманник как-то кошелек вынул, тоже было дело. Но не грабили.

В любом из случаев риски есть, просто разные.