История изменений

Обрати внимание на коммент перед List

Заставь дурака богу молиться, так он лоб себе расшибёт.

Добро пожаловать в мир без аннотаций:

Это аннотации, пусть и в комментариях.

использование лябд делает код не только понятнее но и быстрее.

На специально подобранном примере разница меньше 10%. При том, что я не вижу ни одной причины не компилировать анонимные классы так же, как лямбды, если уж хочется производительности. Т.е. то, что должно оптимизироваться прозрачно для программиста, зачем-то вынесли в фичи языка. Любой код с лямбдой это плохой код. С анонимными классами это хорошо видно, т.к. развесистая байда в глаза бросается и возникает подспудное желание от неё избавиться. От лямбды подспудного желания избавиться не возникает и в этом её проблема, она маскирует плохой код под хороший, хотя лямбда это тот же класс, тот же объект где-то в хипе, те же виртуальные вызовы, в общем куча просранных циклов процессора и байтов памяти.

Интерфейсы не хранят состояний, потому дефолтные методы не проблема.

Ну вон скала с трейтами и состояние может хранить. Описываем абстрактные get/set, класс-реализатор их неявно имплементирует, вот тебе и фактическое состояние в интерфейсе. Выкрутасов можно много придумать. Только концептуально это неправильно. Пускай тогда вводят множественное наследование и голову не дурят.

И их ввод следствие введения лямбд. Кому нужны лямбды если их нельзя использовать против существующих реализаций коллекций?

List интерфейс, в AbstractList добавить все нужные методы, всё, какие проблемы? Изначально надо было сделать IList < List, конечно, но и сейчас это не концептуальная проблема.

Обрати внимание на коммент перед List

Заставь дурака богу молиться, так он лоб себе расшибёт.

Добро пожаловать в мир без аннотаций:

Это аннотации, пусть и в комментариях.

использование лябд делает код не только понятнее но и быстрее.

На специально подобранном примере разница меньше 10%. При том, что я не вижу ни одной причины не компилировать анонимные классы так же, как лямбды, если уж хочется производительности. Т.е. то, что должно оптимизироваться прозрачно для программиста, зачем-то вынесли в фичи языка. Любой код с лямбдой это плохой код. С анонимными классами это хорошо видно, т.к. развесистая байда в глаза бросается и возникает подспудное желание от неё избавиться. От лямбды подспудного желания избавиться не возникает и в этом её проблема, она маскирует плохой код под хороший, хотя лямбда это тот же класс, тот же объект где-то в хипе, те же виртуальные вызовы, в общем куча просранных циклов процессора и байтов памяти.

Интерфейсы не хранят состояний, потому дефолтные методы не проблема.

Ну вон скала с трейтами и состояние может хранить. Описываем абстрактные get/set, класс-реализатор их неявно имплементирует, вот тебе и фактическое состояние в интерфейсе. Выкрутасов можно много придумать. Только концептуально это неправильно. Пускай тогда вводят множественное наследование и голову не дурят.

И их ввод следствие введения лямбд. Кому нужны лямбды если их нельзя использовать против существующих реализаций коллекций?

List интерфейс, в AbstractList добавить все нужные методы, всё, какие проблемы?