какой нить unmodifiable?

я ковыряю легаси код Ланита

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

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

скажем так, если результат мы потом не модицируем, то нам пофик

а если модицифируем, то надо в ArrayList

Ну модификация результата немного не про streams

Сначала стримами фильтруем и мапим, а потом результат через итератор модифицируем?)

то есть стрим все таки возвращает немодифицируемый лист?

то есть стрим все таки возвращает немодифицируемый лист?

насколько помню, там внутри тот же самый ArrayList::new

можно глянуть сорцы

Ну модификация результата немного не про streams

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

то есть стрим все таки возвращает немодифицируемый лист?

Для toList нет гарантии какой будет тип листа

можно глянуть сорцы

однако контракт этого не обещает.

однако контракт этого не обещает.

именно это и был мой поинт выше

Сначала стримами фильтруем и мапим, а потом результат через итератор модифицируем?)

почему через итератор-то. мне может надо долить данных

почему через итератор-то. мне может надо долить данных

в arraylist?)

почему нет?

так это уже будет новый list

ээээ... шта?!

add или addAll порождают новый лист?

или таки вызываются на имеющемся?

public boolean addAll(Collection<? extends E> c) { Object[] a = c.toArray(); int numNew = a.length; ensureCapacityInternal(size + numNew); // Increments modCount System.arraycopy(a, 0, elementData, size, numNew); size += numNew; return numNew != 0; }

https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#arraycopy-java.lang.Object-int-java.lang.Object-int-int-

под arraylist лежит массив объектов, а они не умеют динамически менять размер. Когда ты создаешь массив, он получает DEFAULT_CAPACITY, либо тот, который ты указываешь. Добавляя элементы сверх этой нормы массив под низом нужно пересоздать, копируя в него все из предыдущего.

молодец

you can read! как говорится

you can read! как говорится

❤️

только мысль была в том что если toList вернёт unmodifiable, то хрен ты на нём вызовешь addAll

и если тебе надо гарантировать тип объекта, чтобы не развалить кусок дальнейшей логики, toCollection (AL:new) вполне ок

public static <T> Collector<T, ?, List<T>> toList() { return new CollectorImpl<>((Supplier<List<T>>) ArrayList::new, List::add, (left, right) -> { left.addAll(right); return left; }, CH_ID); }

а мемкопи в современном мире настолько грошовое, что говорить про его стоимость как-то даже... стыдно

и если тебе надо гарантировать тип объекта, чтобы не развалить кусок дальнейшей логики, toCollection (AL:new) вполне ок

Я и не был против изначально, не знаю почему ты думаешь, что я другого мнения

public static <T> Collector<T, ?, List<T>> toList() { return new CollectorImpl<>((Supplier<List<T>>) ArrayList::new, List::add, (left, right) -> { left.addAll(right); return left; }, CH_ID); }

и? это прописано в джавадоке?

я вообще не спорю. я сказал зачем может понадобиться эррейлист - "долить данных"

дальше пошла какая-то мура про "выделение памяти"

Специально для тебя

* Returns a {@code Collector} that accumulates the input elements into a * new {@code List}. There are no guarantees on the type, mutability, * serializability, or thread-safety of the {@code List} returned; if more * control over the returned {@code List} is required, use {@link #toCollection(Supplier)}.

Все, я кончил

угу. поэтому та странная конструкция имеет право на жизнь. ну, как бы

Все, я кончил

и заляпал нам весь чат. убирай.

public static <T> Collector<T, ?, List<T>> toList() { return new CollectorImpl<>((Supplier<List<T>>) ArrayList::new, List::add, (left, right) -> { left.addAll(right); return left; }, CH_ID); }

огонь

я ковыряю легаси код Ланита

Охренеть, Жава 8 уже легаси?

ну вообще то да)

но речь не о джаве, а о коде

++

но речь не о джаве, а о коде

++

у меня вот тут проекту 2 месяца, он уже легаси..

Охренеть, Жава 8 уже легаси?

Ну так то 4 года назад вышла) уже того..

Ну так то 4 года назад вышла) уже того..

Ну пока восьмерка ЛТС, она не может быть легаси

Хотя, если вдуматься в значение слова — все что угодно может быть легаси

Все что написано человеком, который уже уволился — легаси ))

Даже если он вчера написал и сегодня уволился и переложил на тебя свой говнокод ))

Ну пока восьмерка ЛТС, она не может быть легаси

Ну значит скоро станет) выход 11 по идее уже скоро

Все что написано человеком, который уже уволился — легаси ))

нет

всё, что страшно рефакторить - легаси

вдруг человек хорошо писал и ушёл так, что ему даже в спину не плюнули..

всё, что страшно рефакторить - легаси

Согласен

Другими словами легаси — это унаследованный техдолг

да

но

как сказал один лысый - весь мир основан на долгах

главное вовремя закрывать наиболее дорогие

Всем доброго! Ребята а можете подсказать, кто какие паттерны использует или просто считает обязательными для частого применения. 3-4 штуки?

стратегия конечно

ERROR: S client not available

потом конечно же мост

затем синглетон

затем фактори

а там еще может подтянутся фасад

за которым скрывается прокси и флайвейт

ну конечно это все должно быть в адаптере

который обвещан тремя декораторами

и создается как прототип

с отложеной инициализацией

и в фабричном методе хранителя

нарвался на ответ называется ?

ну а чо

как говорится

Roses are red, leaves are green, but only Java has AbstractSingletonProxyFactoryBean

ты лучше расскажи зачем тебе это понадобилось то в 2018 году

а что в 2018 паттерны не нужны?

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

вот стало интересно спросить тут мнение, в java сообществе

Каждый выебщик считает обязательным именно то, в чём он сам хорошо разбирается

Не обращай внимание

примерно 99% паттернов, которые ты используешь постоянно, ты не выделяешь как паттерны. ты их просто юзаешь. вообще вопрос про паттерны выглядит как отсылка к собеседованиям.

ну создал ты коллекцию с кастомным компаратором

ты же не проговариваешь в голове "а вот тут я использовал паттерн СТРАТЕГИЯ"

(надеюсь)

примерно 99% паттернов, которые ты используешь постоянно, ты не выделяешь как паттерны. ты их просто юзаешь. вообще вопрос про паттерны выглядит как отсылка к собеседованиям.

Ну не 99%. Часто используется понятия Builder, Proxy, фабрика и фабричный метод.

Да и слова фасад и декоратор в повседневной разработке используются.

Да и слова фасад и декоратор в повседневной разработке используются.

вот примерно в таком контексте был разговор, не то что бы панацея, но с ними мол намного намного лучше

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

наверное....

Ну вот относительно недавно меня даж один парень спрашивал, мол, правильно ли он понимает паттерн Стратегия.

Выяснилось, что его неправильно понимаю я))0)

В общим, такие разговоры — норм, если в тему, ящетаю.