Re[4]: Поругайте TypeScript/node.js
От: vsb Казахстан  
Дата: 26.06.22 08:14
Оценка:
Здравствуйте, Shtole, Вы писали:

vsb>>С чего ты вообще взял, что кто-то протёк? Ты закрыл страницы и память не вернулась?


S>Во-первых, помог только kill process tree.


Не понял, что это значит.

S>Во-вторых, не понял юмора. Я как пользователь должен переоткрывать страницу после ресайза туда-сюда, чтобы не пришлось программы закрывать, когда винда жалуется на нехватку памяти? Это такие сейчас стандарты качества?


Если страница просит память и в системе память есть, браузер её даёт. Какие проблемы-то? Ты от маллока требуешь, чтобы он оценивал моральные качества твоей программы или чтобы он давал тебе запрошенную память?

Поэтому да, если сайт так написан, что жрёт память, значит переоткрывай страницу, а лучше найди не такой прожорливый сайт.
Re[6]: Поругайте TypeScript/node.js
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.06.22 09:20
Оценка:
Здравствуйте, Буравчик, Вы писали:

P>>Похоже, ктото не знает, что такое типизация. Линтер это детский сад по сравнению с ТайпСкриптом.


Б>Похоже, кто-то не знает, как работает статическая проверка типов в питон, что такое аннотации типов и mypy.


Я то как раз знаю. Линтинг, про который ты говоришь, это ничтожная часть того, что может давать статическая типизация. Прежде всего это инструмент проектирования, это основная задача, а уже потом — подсказки, кодинг, линтинг итд.
mypy соответствует TypeScript времен примерно 10ти летней давности
Re[7]: Поругайте TypeScript/node.js
От: Буравчик Россия  
Дата: 26.06.22 09:42
Оценка:
Здравствуйте, Pauel, Вы писали:

P>Я то как раз знаю. Линтинг, про который ты говоришь, это ничтожная часть того, что может давать статическая типизация. Прежде всего это инструмент проектирования, это основная задача, а уже потом — подсказки, кодинг, линтинг итд.


Разверни свою мысль про "инструмент проектирования".
Чем типизация в питоне отличается от TS в плане проектирования?

P>mypy соответствует TypeScript времен примерно 10ти летней давности


Неубедительно. Хочется примеров
Best regards, Буравчик
Re[5]: Поругайте TypeScript/node.js
От: · Великобритания  
Дата: 26.06.22 09:53
Оценка:
Здравствуйте, Pauel, Вы писали:

P>>>regex-redux — в три раза

P>·>Ты не тот исходник показываешь. Вот оно, под капотом. Это не node быстрый, а C++. В java же честная имплементация.
P>Как и на чем они работают — вообще не интересно. Я ж за это не плачу нисколько. Получается — все что на регексах будет втрое быстрее.
Т.е. ты смотришь на сравнение c++ vs java и из этого хочешь сделать вывод о производительности js?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[11]: Поругайте TypeScript/node.js
От: · Великобритания  
Дата: 26.06.22 09:57
Оценка:
Здравствуйте, Pauel, Вы писали:

P>>>А ты разберись, что это такое. Тайпскрипт не исправляет жээс,

P>·>Это демагогия. Типизация — тоже исправляет, в прямом смысле этого слова, чтобы компилятор ловил попытки выстрелить в ногу.
P>Не исправляет. Все косяки джаваскрипта доступны и в тайпскрипте. Тайпскрипт это надмножество джаваскрипта.
Что значит "все"? Давай конкретику. В js можно присвоить любому объекту любое свойство. В typescript это будет ошибка компиляции. Понятно, что можно явным образом отключить проверку типов в куске ts кода, но это явное действие. В моём примере же это просто дыра в системе типов ts, и никакого отношения к js не имеет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[8]: Поругайте TypeScript/node.js
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.06.22 09:58
Оценка:
Здравствуйте, Буравчик, Вы писали:

P>>Я то как раз знаю. Линтинг, про который ты говоришь, это ничтожная часть того, что может давать статическая типизация. Прежде всего это инструмент проектирования, это основная задача, а уже потом — подсказки, кодинг, линтинг итд.


Б>Разверни свою мысль про "инструмент проектирования".


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

Б>Чем типизация в питоне отличается от TS в плане проектирования?


Мы про твоё утверждение, где статическая типизация вдруг выродилась в линтинг. Подозреваю, ты сейчас хочешь поменять задним числом смысл высказывания, что следует из того, что ты притягиваешь mypy как аргумент.

P>>mypy соответствует TypeScript времен примерно 10ти летней давности


Б>Неубедительно. Хочется примеров


http://rsdn.org/forum/philosophy/7967480.1
Автор: Ikemefula
Дата: 09.03.21

http://rsdn.org/forum/philosophy/7835882.1
Автор: Ikemefula
Дата: 22.09.20
Отредактировано 26.06.2022 12:08 Pauel . Предыдущая версия .
Re[3]: Поругайте TypeScript/node.js
От: Слава  
Дата: 26.06.22 21:13
Оценка: 3 (1)
Здравствуйте, Артём, Вы писали:

Аё>Не нужно на JS VM пенять, коли код течет. Можно сказать, что течет в эко-системе, да, это факт. У нас течет в кишках ангулар (и не только там). Однако, GC ругать за утекшие в статик обьекты, неправильно.


А покажите мне пальцем где хоть в одном браузере имеется настройка ограничений по памяти для домена и его поддоменов, вкладки и группы вкладок, а также запущенных оттуда service worker'ов?

Сделали из браузера операционку, а инструменты добавить забыли.
Re[5]: Поругайте TypeScript/node.js
От: Слава  
Дата: 26.06.22 21:58
Оценка: 4 (2)
Здравствуйте, vsb, Вы писали:

S>>Во-первых, помог только kill process tree.


Вот ровно это самое и значит. Это опция такая в диспетчере задач в Винде.

Между прочим, в Винде же с давних времён имеется способ ограничить потребление памяти процессом и его потомками, job objects, и оно доступно начиная с windows 2000. Однако же, шибко вумный Google Chrome сам использует джобы, но только не даёт их настраивать, а вложенных джобов в винде не было доступно вплоть до Windows 8. То есть, запускаешь Хром в джобе, и он помирает сразу при запуске. Ещё Хром не позволял себя запускать под отдельным пользователем, через runas. Это выглядит осознанной подлостью: убрать возможность применить ограничения к браузеру.
Отредактировано 27.06.2022 13:20 Слава . Предыдущая версия .
Re[12]: Поругайте TypeScript/node.js
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.06.22 08:35
Оценка:
Здравствуйте, ·, Вы писали:

P>>>>А ты разберись, что это такое. Тайпскрипт не исправляет жээс,

P>>·>Это демагогия. Типизация — тоже исправляет, в прямом смысле этого слова, чтобы компилятор ловил попытки выстрелить в ногу.
P>>Не исправляет. Все косяки джаваскрипта доступны и в тайпскрипте. Тайпскрипт это надмножество джаваскрипта.
·>Что значит "все"? Давай конкретику. В js можно присвоить любому объекту любое свойство. В typescript это будет ошибка компиляции.

Конечно же это не так. Ты про тайпскрипт похоже что только читал. В тайпскрипт, что бы присвоить любому объекту любое свойство нужно или добавить описание типа, или включить некоторые опции компилятора. То есть, нет проблемы добиться идентичного поведения — присваивай что хошь куда хошь.
Похоже, ты не в курсе что Тайпскрипт это надмножество джаваскрипта. Гы.

> Понятно, что можно явным образом отключить проверку типов в куске ts кода, но это явное действие. В моём примере же это просто дыра в системе типов ts, и никакого отношения к js не имеет.


Алё — ты сделал явное преобразование типа! Коллекции джавы позволяют спокойно добавить собаку в массив котов, использую всего лишь преобразование к базовому классу коллекции. Соответсвенно при итерации ты получишь ... приплызд.
Аналогичный фокус есть и в дотнете.
То есть, эта самая дырка есть почти что во всех мейнстримных языках, а в Си/Си++ это вообще норма жизни. И ничего, живут люди.
Отредактировано 27.06.2022 8:43 Pauel . Предыдущая версия .
Re[6]: Поругайте TypeScript/node.js
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.06.22 08:40
Оценка: -1
Здравствуйте, ·, Вы писали:

P>>Как и на чем они работают — вообще не интересно. Я ж за это не плачу нисколько. Получается — все что на регексах будет втрое быстрее.

·>Т.е. ты смотришь на сравнение c++ vs java и из этого хочешь сделать вывод о производительности js? :facepalm

А ты, как всегда, отвечаешь только на какие то фрагменты. Разуй глаза — я привел ссылку, где много бенчмарков. Там, где не регекспы и не многопоточность, ситуация 1 к 1.

На чем написаны регекспы — вообще не интересно. Важно, какой перформанс выдаст прикладной код.

К слову, как думаешь, на чем сделана многопоточность джавы? На джаве? Гы-гы. Итого — когда сравнение в твою пользу, тебя не заботит, что там унутре за неонка. А если сравнение не в твою пользу — появляются "а там не та неонка!!!!1111"

Или ты не в курсе, что в джаве полно нативных интринсиков? Бу-га-га.

То есть, в сумме, в джаве и джаваскрипте разница только в интринсиках.
Отредактировано 27.06.2022 8:42 Pauel . Предыдущая версия .
Re[13]: Поругайте TypeScript/node.js
От: · Великобритания  
Дата: 27.06.22 09:56
Оценка:
Здравствуйте, Pauel, Вы писали:

P>·>Что значит "все"? Давай конкретику. В js можно присвоить любому объекту любое свойство. В typescript это будет ошибка компиляции.

P>Конечно же это не так. Ты про тайпскрипт похоже что только читал. В тайпскрипт, что бы присвоить любому объекту любое свойство нужно или добавить описание типа, или включить некоторые опции компилятора. То есть, нет проблемы добиться идентичного поведения — присваивай что хошь куда хошь.
Я знаю. Ты не понял, что я написал. В ts нельзя присвоить любое свойство любому объекту, а только то, что разрешено в системе типов. Т.е. в моём примере ты не можешь в ts написать ro.y.

>> Понятно, что можно явным образом отключить проверку типов в куске ts кода, но это явное действие. В моём примере же это просто дыра в системе типов ts, и никакого отношения к js не имеет.

P>Алё — ты сделал явное преобразование типа!
Ты хоть доки почитай, поищи как выглядит явное преобразование типа. Я не делал явное преобразование типа. Я мог просто вызвать метод с таким типом аргумента. Например так:
interface Ro {
    readonly x: string;
}

const modify = (rw: {x: string;}) => rw.x = 'bye';
const use = (v: Ro) => {
    console.log(v.x);

    //v.x = 'bye'; Compiler error: "Cannot assign to 'x' because it is a read-only property.". Хорошо!
    modify(v);// No errors, not even warnings. Всё молча отрабатывает.
}
const ro: Ro = {x: "hi"}
use(ro);
console.log(ro.x);// readonly field поменялось молча!


P> Коллекции джавы позволяют спокойно добавить собаку в массив котов, использую всего лишь преобразование к базовому классу коллекции. Соответсвенно при итерации ты получишь ... приплызд.

Нет, коллекции джавы не позволяют. https://stackoverflow.com/questions/44819476/covariance-in-java-collection-cannot-be-added-to

P>Аналогичный фокус есть и в дотнете.

Ну значит тоже дырявое поделие микрософта.

P>То есть, эта самая дырка есть почти что во всех мейнстримных языках, а в Си/Си++ это вообще норма жизни. И ничего, живут люди.

const_cast же требуется.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[14]: Поругайте TypeScript/node.js
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.06.22 11:03
Оценка:
Здравствуйте, ·, Вы писали:

P>> Коллекции джавы позволяют спокойно добавить собаку в массив котов, использую всего лишь преобразование к базовому классу коллекции. Соответсвенно при итерации ты получишь ... приплызд.

·>Нет, коллекции джавы не позволяют. https://stackoverflow.com/questions/44819476/covariance-in-java-collection-cannot-be-added-to

P>>Аналогичный фокус есть и в дотнете.

·>Ну значит тоже дырявое поделие микрософта.

https://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/concepts/covariance-contravariance/

Да ты можешь присвоить масииву с базовым типом. Но вот добавить нет.

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


object[] array = new String[10];  
// The following statement produces a run-time exception.  
// array[0] = 10;
и солнце б утром не вставало, когда бы не было меня
Re[7]: Поругайте TypeScript/node.js
От: · Великобритания  
Дата: 27.06.22 11:11
Оценка:
Здравствуйте, Pauel, Вы писали:

P>>>Как и на чем они работают — вообще не интересно. Я ж за это не плачу нисколько. Получается — все что на регексах будет втрое быстрее.

P>·>Т.е. ты смотришь на сравнение c++ vs java и из этого хочешь сделать вывод о производительности js? :facepalm
P>А ты, как всегда, отвечаешь только на какие то фрагменты. Разуй глаза — я привел ссылку, где много бенчмарков. Там, где не регекспы и не многопоточность, ситуация 1 к 1.
Я как раз таки разул. Смотрим, скажем pidigits. Ух-ты! "Node js #4" работает почти так же быстро, памяти жрёт чуток больше, круто... но смотрим в исходник и видим require('mpzjs') "This library wraps around libgmp" Опять сравнение java vs c с++ и ассемблерными вставками. А вот честный код на ноде "Node js #2" уже на порядок медленее и дважды прожорливее.

P>На чем написаны регекспы — вообще не интересно. Важно, какой перформанс выдаст прикладной код.

Если у меня внезапно проект с кучей регекспов (боже упаси), то я могу легко подключить любую другую либу с регекспами, в т.ч. и нативную.

P>К слову, как думаешь, на чем сделана многопоточность джавы? На джаве? Гы-гы. Итого — когда сравнение в твою пользу, тебя не заботит, что там унутре за неонка. А если сравнение не в твою пользу — появляются "а там не та неонка!!!!1111"

На джаве сделана JMM. Многопоточность в виде либы ты к яп подключить не можешь принципиально. Всякие поделия в виде воркеров это лучшее что можно поиметь.

P>Или ты не в курсе, что в джаве полно нативных интринсиков? Бу-га-га.

Это всего лишь perf-optimisation и к яп это отношения не имеет.

P>То есть, в сумме, в джаве и джаваскрипте разница только в интринсиках.

Не только.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[14]: Поругайте TypeScript/node.js
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.06.22 11:20
Оценка:
Здравствуйте, ·, Вы писали:

P>> Коллекции джавы позволяют спокойно добавить собаку в массив котов, использую всего лишь преобразование к базовому классу коллекции. Соответсвенно при итерации ты получишь ... приплызд.

·>Нет, коллекции джавы не позволяют. https://stackoverflow.com/questions/44819476/covariance-in-java-collection-cannot-be-added-to

Смотри внимательно — дыра в джаве с начала времён. Ровно та же проблема, что ты показал, только другие последствия:
import java.util.ArrayList;

class Playground {
    public static void main(String[ ] args) {
        ArrayList<String> languages = new ArrayList<>();
        ArrayList x = languages;

        languages.add("x y z");
        x.add(5); // собака в массиве котов

        System.out.println(languages.get(1)); // любуешься разницей, а что будет если передавать 0 и 1
    }
}


Скажем, если ты передашь не того наследника, то ровно как и в жээсе, узнаешь об этом только в самый последний момент.

P>>То есть, эта самая дырка есть почти что во всех мейнстримных языках, а в Си/Си++ это вообще норма жизни. И ничего, живут люди.

·>const_cast же требуется.

Совсем необязательно. Зависит от многих вещей, особенно в Си.
Отредактировано 27.06.2022 11:28 Pauel . Предыдущая версия .
Re[15]: Поругайте TypeScript/node.js
От: · Великобритания  
Дата: 27.06.22 11:21
Оценка:
Здравствуйте, Serginio1, Вы писали:


S>
S>object[] array = new String[10];  
S>// The following statement produces a run-time exception.  
S>// array[0] = 10; 
S>

Голые массивы в Java так же (думаешь откуда c# списывали?). А коллекции (java.util.Collection) так не позволяют, будет compile-time error. Не знаю как в c#.
List<Integer> ints = List.of(1, 2, 3);
//List<Number> nums = ints;//compiler error "incompatible types"
List<? extends Number> nums = ints;//ok
assert nums.get(0) instanceof Integer;
//nums.add(1.1);//compiler error "type mismatch"
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[8]: Поругайте TypeScript/node.js
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.06.22 11:39
Оценка: -1
Здравствуйте, ·, Вы писали:

·>Я как раз таки разул. Смотрим, скажем pidigits. Ух-ты! "Node js #4" работает почти так же быстро, памяти жрёт чуток больше, круто... но смотрим в исходник и видим require('mpzjs') "This library wraps around libgmp" Опять сравнение java vs c с++ и ассемблерными вставками. А вот честный код на ноде "Node js #2" уже на порядок медленее и дважды прожорливее.


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

P>>На чем написаны регекспы — вообще не интересно. Важно, какой перформанс выдаст прикладной код.

·>Если у меня внезапно проект с кучей регекспов (боже упаси), то я могу легко подключить любую другую либу с регекспами, в т.ч. и нативную.

Ну так подключай, кто мешает?

P>>К слову, как думаешь, на чем сделана многопоточность джавы? На джаве? Гы-гы. Итого — когда сравнение в твою пользу, тебя не заботит, что там унутре за неонка. А если сравнение не в твою пользу — появляются "а там не та неонка!!!!1111"

·>На джаве сделана JMM. Многопоточность в виде либы ты к яп подключить не можешь принципиально. Всякие поделия в виде воркеров это лучшее что можно поиметь.

Именно — интринсик на нативном инструменте. Ровно так же можно и в ноде, только ты про это не в курсе.

P>>То есть, в сумме, в джаве и джаваскрипте разница только в интринсиках.

·>Не только.

Разница только в этом. Качество либ стремительно уравнивается в т.ч. с точки зрения перформанса.
Re[15]: Поругайте TypeScript/node.js
От: · Великобритания  
Дата: 27.06.22 11:55
Оценка:
Здравствуйте, Pauel, Вы писали:

P>·>Нет, коллекции джавы не позволяют. https://stackoverflow.com/questions/44819476/covariance-in-java-collection-cannot-be-added-to

P>Смотри внимательно — дыра в джаве с начала времён. Ровно та же проблема, что ты показал, только другие последствия:
P> ArrayList x = languages;
Это compiler warning, т.к. явная потеря инфы о типах. Такой код не пройдёт билд с -Werror.
Согласен, плохо, что это всего лишь предупреждение по умолчанию, которое можно случайно проигнорировать по незнанию... но backward compatibility сильная штука.

P>>>То есть, эта самая дырка есть почти что во всех мейнстримных языках, а в Си/Си++ это вообще норма жизни. И ничего, живут люди.

P>·>const_cast же требуется.
P>Совсем необязательно. Зависит от многих вещей, особенно в Си.
Так в Си и нет коллекций и вообще с типами плохо. И плюсы ты тоже не знаешь... A vector<derived *> isn't convertible to a vector<base *> https://stackoverflow.com/questions/9365318/c-can-i-cast-a-vector-derived-class-to-a-vector-base-class-during-a-funct
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[9]: Поругайте TypeScript/node.js
От: · Великобритания  
Дата: 27.06.22 12:09
Оценка:
Здравствуйте, Pauel, Вы писали:

P>·>Я как раз таки разул. Смотрим, скажем pidigits. Ух-ты! "Node js #4" работает почти так же быстро, памяти жрёт чуток больше, круто... но смотрим в исходник и видим require('mpzjs') "This library wraps around libgmp" Опять сравнение java vs c с++ и ассемблерными вставками. А вот честный код на ноде "Node js #2" уже на порядок медленее и дважды прожорливее.

P>Это никому не интересно, какая унутре неонка. До тех пор, пока это не доставляет проблем с деплойментом и про это не надо думать, нет смысла выстраивать здесь огород
Интересно тем, кто пишет код, которому нужна хоть какая-то производительность. На ноде ты не сможешь писать производительный код, в лучшем случае писать код-обёртку для нативных либ (если они есть для твоих задач).

P>>>На чем написаны регекспы — вообще не интересно. Важно, какой перформанс выдаст прикладной код.

P>·>Если у меня внезапно проект с кучей регекспов (боже упаси), то я могу легко подключить любую другую либу с регекспами, в т.ч. и нативную.
P>Ну так подключай, кто мешает?
Никто не мешает. Просто нативное нафиг не нужно в подавляющем большинстве случаев, и вносит дополнительные риски и сложности в проект.

P>>>К слову, как думаешь, на чем сделана многопоточность джавы? На джаве? Гы-гы. Итого — когда сравнение в твою пользу, тебя не заботит, что там унутре за неонка. А если сравнение не в твою пользу — появляются "а там не та неонка!!!!1111"

P>·>На джаве сделана JMM. Многопоточность в виде либы ты к яп подключить не можешь принципиально. Всякие поделия в виде воркеров это лучшее что можно поиметь.
P>Именно — интринсик на нативном инструменте. Ровно так же можно и в ноде, только ты про это не в курсе.
Интринзик и нативные либы это, мягко говоря, не одно и то же. Ты не поверишь, но даже в плюсах есть интринзики. Наверняка, на твоей планете нода быстрее и плюсов и всего на свете!
И вообще неясно почему ты интринзики помянул в реплике про многопоточность. Похоже, ты не в курсе что такое JMM.

P>>>То есть, в сумме, в джаве и джаваскрипте разница только в интринсиках.

P>·>Не только.
P>Разница только в этом. Качество либ стремительно уравнивается в т.ч. с точки зрения перформанса.
Разница в том, что либы-то нативные. Спрашивается тогда на кой вообще этот node? Пиши сразу на плюсах.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 27.06.2022 13:08 · . Предыдущая версия .
Re[4]: Поругайте TypeScript/node.js
От: Privalov  
Дата: 27.06.22 12:15
Оценка:
Здравствуйте, Shtole, Вы писали:

S>В экосистеме, которая называется Хром. Рядом стоит FF, и он не течёт.


FF починили? Он же тек раньше безбожно. Я от него после 26-й версии отказался. Ушел на Хромую Оперу.
Re[16]: Поругайте TypeScript/node.js
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.06.22 12:50
Оценка:
Здравствуйте, ·, Вы писали:

·>Здравствуйте, Serginio1, Вы писали:



S>>
S>>object[] array = new String[10];  
S>>// The following statement produces a run-time exception.  
S>>// array[0] = 10; 
S>>

·>Голые массивы в Java так же (думаешь откуда c# списывали?). А коллекции (java.util.Collection) так не позволяют, будет compile-time error. Не знаю как в c#.
·>
·>List<Integer> ints = List.of(1, 2, 3);
·>//List<Number> nums = ints;//compiler error "incompatible types"
·>List<? extends Number> nums = ints;//ok
·>assert nums.get(0) instanceof Integer;
·>//nums.add(1.1);//compiler error "type mismatch"
·>


Ну ты про ковариантность и контрвариантность читал? https://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/concepts/covariance-contravariance/variance-in-generic-interfaces

IList не является ковариативным, но IEnumerable является.
и солнце б утром не вставало, когда бы не было меня
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.