Исправление
Legioner,
(текущая версия)
:
Обрати внимание на коммент перед List
Заставь дурака богу молиться, так он лоб себе расшибёт.
Добро пожаловать в мир без аннотаций:
Это аннотации, пусть и в комментариях.
использование лябд делает код не только понятнее но и быстрее.
На специально подобранном примере разница меньше 10%. При том, что я не вижу ни одной причины не компилировать анонимные классы так же, как лямбды, если уж хочется производительности. Т.е. то, что должно оптимизироваться прозрачно для программиста, зачем-то вынесли в фичи языка. Любой код с лямбдой это плохой код. С анонимными классами это хорошо видно, т.к. развесистая байда в глаза бросается и возникает подспудное желание от неё избавиться. От лямбды подспудного желания избавиться не возникает и в этом её проблема, она маскирует плохой код под хороший, хотя лямбда это тот же класс, тот же объект где-то в хипе, те же виртуальные вызовы, в общем куча просранных циклов процессора и байтов памяти.
Интерфейсы не хранят состояний, потому дефолтные методы не проблема.
Ну вон скала с трейтами и состояние может хранить. Описываем абстрактные get/set, класс-реализатор их неявно имплементирует, вот тебе и фактическое состояние в интерфейсе. Выкрутасов можно много придумать. Только концептуально это неправильно. Пускай тогда вводят множественное наследование и голову не дурят.
И их ввод следствие введения лямбд. Кому нужны лямбды если их нельзя использовать против существующих реализаций коллекций?
List интерфейс, в AbstractList добавить все нужные методы, всё, какие проблемы? Изначально надо было сделать IList < List, конечно, но и сейчас это не концептуальная проблема.
Исходная версия
Legioner,
:
Обрати внимание на коммент перед List
Заставь дурака богу молиться, так он лоб себе расшибёт.
Добро пожаловать в мир без аннотаций:
Это аннотации, пусть и в комментариях.
использование лябд делает код не только понятнее но и быстрее.
На специально подобранном примере разница меньше 10%. При том, что я не вижу ни одной причины не компилировать анонимные классы так же, как лямбды, если уж хочется производительности. Т.е. то, что должно оптимизироваться прозрачно для программиста, зачем-то вынесли в фичи языка. Любой код с лямбдой это плохой код. С анонимными классами это хорошо видно, т.к. развесистая байда в глаза бросается и возникает подспудное желание от неё избавиться. От лямбды подспудного желания избавиться не возникает и в этом её проблема, она маскирует плохой код под хороший, хотя лямбда это тот же класс, тот же объект где-то в хипе, те же виртуальные вызовы, в общем куча просранных циклов процессора и байтов памяти.
Интерфейсы не хранят состояний, потому дефолтные методы не проблема.
Ну вон скала с трейтами и состояние может хранить. Описываем абстрактные get/set, класс-реализатор их неявно имплементирует, вот тебе и фактическое состояние в интерфейсе. Выкрутасов можно много придумать. Только концептуально это неправильно. Пускай тогда вводят множественное наследование и голову не дурят.
И их ввод следствие введения лямбд. Кому нужны лямбды если их нельзя использовать против существующих реализаций коллекций?
List интерфейс, в AbstractList добавить все нужные методы, всё, какие проблемы?