@jvmchat

« Назад

Страница 733 из 2890

Далее »

James Tiberius Kirk ?

26.11.2016
23:05:50

Что-то на эльфийском

ну а вообще, уврене в жабке не так оно работает

Oleksandr

26.11.2016
23:09:16

https://stackoverflow.com/questions/22725537/using-java-8s-optional-with-streamflatmap

таки не работает

Google

Oleksandr

26.11.2016
23:09:48

вообще похоже на косяк в дизайне стримов

James Tiberius Kirk ?

26.11.2016
23:09:48

http://stackoverflow.com/questions/22725537/using-java-8s-optional-with-streamflatmap

цук(

ну в девятке обещают пофиксеть

Oleksandr

26.11.2016
23:11:56

Stream<T> stream() { return map(stream::of).orElse(Stream.empty()); }

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

James Tiberius Kirk ?

26.11.2016
23:13:07

Stream<T> stream() { return map(stream::of).orElse(Stream.empty()); }

это реализация Optional.stream()?)

Oleksandr

26.11.2016
23:13:14

https://bugs.openjdk.java.net/browse/JDK-8050820

или не туда смотрю?

я про вот это из ответа на SO: Optional<Other> result = things.stream() .map(this::resolve) .flatMap(Optional::stream) .findFirst();

выглядит страшно

если resolve возвращает Optional, почему нельзя просто взять и сразу .flapMap(this::resolve) ?

Stanislav

27.11.2016
00:06:42

пока примерно вот так выглядит: public static <Type> CompletableFuture<List<Type>> afterAll(CompletableFuture<Optional<Type>>... futures) { return CompletableFuture.allOf(futures) .thenApply((done) -> Arrays.stream(futures) .map(CompletableFuture::join) .filter(Optional::isPresent) .map(Optional::get) .collect(Collectors.toList())); }

у меня для такого есть специальный коллектор, который из Stream<ComplitableFuture<T>> cоздает ComplitableFuture<Collection<T>>

Google

Stanislav

27.11.2016
00:10:14

для твоего случая с Optional было бы так: CompltableFuture<Stream<T>> notNullsOfT = Stream.of(cf1 , ..., cfN) .collect( toCollectionFuture() ) .thenApply( Collection::stream ) .thenApply( stream -> steam .filter( Optional::isPresent ) .map( Optional::get ))

где toCollectionFuture() -- это собственно коллектор

но от страшненького .filter( Optional::isPresent ).map( Optional::get ) не спсает конечно

в принципе, можно toCollectionFuture() сделать таким, чтобы Optional.empty() убирал

Nikita

27.11.2016
01:34:32

Подскажите, в спринге non-identifying relationship, задается как @OneToOne(optional = true), а identifying : optional = false?

Maksim

27.11.2016
07:13:52

https://habrahabr.ru/post/316204/ Ха-ха. Скала, похоже, откажется от Optional в пользу nullable-типов. Если не откажется, то по крайней мере добавит их.

Daniel

27.11.2016
07:49:04

https://habrahabr.ru/post/316204/ Ха-ха. Скала, похоже, откажется от Optional в пользу nullable-типов. Если не откажется, то по крайней мере добавит их.

Это как же прочитать надо было, чтоб такой вывод сделать.

Alexander

27.11.2016
08:15:22

мне бы что-то конкретно по алгритмам классам алгоритмов анализу сложности

https://www.amazon.com/Algorithm-Design-Manual-Steven-Skiena/dp/1848000693

Антон

27.11.2016
08:37:11

https://github.com/aol/cyclops-react Кто-нибудь использует? Половина всех велосипедов можно выкинуть типа как тот что я сверху писал. .

James Tiberius Kirk ?

27.11.2016
08:39:58

Обычные типы не смогут быть null по дефолту. Значения, пришедшие из Java-кода всегда будут опциональными. очень круто

Антон

27.11.2016
10:28:04

в принципе, можно toCollectionFuture() сделать таким, чтобы Optional.empty() убирал

Ага, убрал всю вакханалию в коллектор. Получилось примерно так

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

Igor

27.11.2016
10:38:33

передаём привет монаде traversable

James Tiberius Kirk ?

27.11.2016
11:37:56

Красиво

Stanislav

27.11.2016
11:44:53

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

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

Антон

27.11.2016
11:45:56

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

Окей, в любом случае CompletableFuture.allOff завершится с ошибкой если какая-либо из зафейлилась

коллекцию я готов указывать, в виде того же коллектора

для порядка есть ordered() у стрима

итого в паблик апи только коллектор для коллекции указать

Stanislav

27.11.2016
11:47:19

Если честно решать общий случай с учётом рейсов и parallelStream, то там и медленно и некрасивое api будет

Google

Антон

27.11.2016
11:47:35

а тут прямо быстро )

и суперкрасиво

Stanislav

27.11.2016
11:48:14

Окей, в любом случае CompletableFuture.allOff завершится с ошибкой если какая-либо из зафейлилась

Вот поэтому CF.allOff нерабочее говно и ширпотреб

Антон

27.11.2016
11:48:41

ну меня такое поведение устраивает в данном случае

ну и это логично

если тебе интересны все фьючеры - то логично чтобы они все завершились успешно

в противном случае есть anyOf

вообще нужно потыкать палкой в https://github.com/aol/cyclops-react

Stanislav

27.11.2016
11:50:50

AnyOf сразу вылетает при первом эксепшоне, насколько я помню

Антон

27.11.2016
11:51:55

Returns a new CompletableFuture that is completed when any of * the given CompletableFutures complete, with the same result. * Otherwise, if it completed exceptionally, the returned * CompletableFuture also does so, with a CompletionException * holding this exception as its cause. If no CompletableFutures * are provided, returns an incomplete CompletableFuture.

ну вообще да

гавно

Антон

27.11.2016
11:52:30

неочевидная шляпа

Stanislav

27.11.2016
11:52:41

Ну вот самый общий случай, это коллектить Either<T, Throwable>

Но потом с ними работать заебешься

Антон

27.11.2016
11:53:04

а потом собирать

ну да

поставлю тудуху себе

Maksim

27.11.2016
12:28:42

Это как же прочитать надо было, чтоб такой вывод сделать.

А что я не так прочитал? • Обычные типы не смогут быть null по дефолту. Значения, пришедшие из Java-кода всегда будут опциональными. T? = T | Null val stream: PrintStream? = System.out.printStream Насколько я помню, у скалы был только Optional до этого, разве нет?

Daniel

27.11.2016
12:59:30

> Значения, пришедшие из Java-кода всегда будут опциональными. как бы намекает что Option останется

Google

Oleksandr

27.11.2016
13:23:39

мне тоже фича с ? не нравится, опшны фундаментальнее

Берял

27.11.2016
13:24:05

идиоматичнее

Oleksandr

27.11.2016
13:24:11

и будет три (минимум) способы работать с наллами надеюсь, не введут

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

и вообще не ясно, как сделать "Значения, пришедшие из Java-кода всегда будут опциональными" как это в котлине делается, на уровне IDE?

Andrey

27.11.2016
13:38:03

и вообще не ясно, как сделать "Значения, пришедшие из Java-кода всегда будут опциональными" как это в котлине делается, на уровне IDE?

Нет, компилятора. Причём тут IDE?

Admin

ERROR: S client not available

Oleksandr

27.11.2016
13:38:37

Нет, компилятора. Причём тут IDE?

как ты из байткода в .class поймешь, что вон то — джава, а вон то — котлин?

(в худшем случае, тебе доступен только байткод)

Andrey

27.11.2016
13:39:30

как ты из байткода в .class поймешь, что вон то — джава, а вон то — котлин?

Они свой хеадер запихивают в .class

Oleksandr

27.11.2016
13:40:25

а, ну тогда ладно

с другой стороны — а точно ли все значения из джава кода надо делать опциональными? если там, скажем, Optional<String>, то глупо будет иметь Optional<String>?

Alex

27.11.2016
13:42:15

Они свой хеадер запихивают в .class

Ммм, CTC хватает за глаза, разве нет?

Andrey

27.11.2016
13:42:41

Ммм, CTC хватает за глаза, разве нет?

CTC?

Alex

27.11.2016
13:42:42

Компайл тайм чек

Andrey

27.11.2016
13:43:30

Компайл тайм чек

А как с помощью этого обнаруживать котлиновские .class?

с другой стороны — а точно ли все значения из джава кода надо делать опциональными? если там, скажем, Optional<String>, то глупо будет иметь Optional<String>?

Не глупо. Там может быть null. Всё-таки нудно полностью покрывать интерпоп.

Oleksandr

27.11.2016
13:45:33

и даже если там @NotNull ?

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

Stanislav

27.11.2016
13:51:39

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

Google

Oleksandr

27.11.2016
13:55:59

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

когда в языке одновременно и ?, и опшн -- это уродство

Stanislav

27.11.2016
13:58:09

Когда в языке и null и опншл -- это уродство

Когда и null, и ? -- хорошо

Andrey

27.11.2016
13:58:34

Как вы называете переменные, если они отражают одну суть. К примеру есть строка, к которой хранится URL и java.net.URL, в которой хранится этот же URL. Как покрасивше назвать переменные?

Stanislav

27.11.2016
13:59:55

Если есть и null, и ?, и опшнл -- то просто бей погромиста, котрый использует опшнл и будет хорошо

Как вы называете переменные, если они отражают одну суть. К примеру есть строка, к которой хранится URL и java.net.URL, в которой хранится этот же URL. Как покрасивше назвать переменные?

String adress и URL url

Но вообще URL -- зло

Andrey

27.11.2016
14:02:12

Но вообще URL -- зло

А что использовать вместо него?

Stanislav

27.11.2016
14:02:58