[moriturius]

Mirki z #programowanie oraz #programowaniefunkcyjne (tutaj nieco mniej obserwujących ;) ). Pomyślałem, że może wam się spodobają treści na moim aktualnym blogu. W dzisiejszym odcinku opisałem do czego służy Optional w Javie 8. Ogólnie zamieszczam i zamierzam zamieszczać treści związane z programowaniem, programowaniem funkcyjnym, #scala, #java i co innego ciekawego przyjdzie mi do głowy :)

Link do aktualnego posta: http://blog.radoszewski.pl/programming/java/2015/04/19/java-optional.html

Miłego czytania!

Ach, zapomniałem wspomnieć, że czytanie odbywa się w języku angielskim!

#autoreklama

[a.....r]

@moriturius: Spoko .. aż jestem ciekaw jak wytłumaczysz monady, bo każdy to tłumaczy w całkowicie inny sposób.

[moriturius]

@archlinuxuser: O kurcze, muszę przyznać, że szybko czytasz :) Postaram się napisać o nich jak najbardziej użytecznie. Napiszę co to jest i co fajnego dostajemy w Scali jeśli z naszych klas zrobimy monady :)

[a.....r]

@moriturius: Aj, to tu mnie zgubiłeś. Scali nie znoszę.
Ale mimo wszystko życzę dużej liczby czytelników :).

[a.....r]

@moriturius: Przeczytałem szybko, bo Optionala znam, szanuję i używam na codzień.

[moriturius]

@archlinuxuser: Czemu nie znosisz scali? Jest dobra na wszelkie próby nauczenia się programowania funkcyjnego bo pozwala ładnie łączyć aspekty tegoż z klasycznym imperatywnym :)

[a.....r]

@moriturius: Dobra do nauczenia, podobnie jak Groovy, którego też nie lubię ;).
Ja tam nie potrzebuję się tego uczyć, potrzebuję prostego (w znaczeniu KISS) i pragmatycznego języka a nie generatorów accidental complexity ;).

[moriturius]

@archlinuxuser: No scala do najprostszych nie należy i to jest chyba jej największy problem ( ͡° ʖ̯ ͡°). Ja długo nie mogłem patrzeć na scalę, ze względu na to jak wyglądała i dlatego, że próg wejścia był dość wysoki. Jakoś to jednak przebolałem i teraz strasznie trudno mi pogodzić się z Javą, która w porównaniu wygląda jak narzędzie z kamienia i patyka ;)

Tak czy inaczej, skoro

[a.....r]

@moriturius: Ja polecam Clojure, z programowania w Scali mam wspomnienia jak z C++-a.

[moriturius]

@archlinuxuser: No Clojure już próbowałem. Jest świetny ze względu na prostotę składni. Ma genialnego nREPLa, ale kurde jakoś nie mogę patrzeć na taką ilość nawiasów :c

[a.....r]

@moriturius: Przeszkadza tylko na początku. Ale znam i rozumiem ten problem bo sam tak miałem :).

[hbpitero]

@moriturius: Trochę faila zaliczyłeś. Trochę bez sensu moim zdaniem pisać o czymś co się słabo ogarnia.

Czemu nie po prostu .map? flatMap generalnie używa się do czegoś zupełnie innego. Przykłady też słabe bo nie uciekasz od nulla (nadal w obrębie klasy używasz nulla i ofNullable), dodatkowo Book::getAuthor nie jest skrótem od book -> book.getAuthor(), "Optional" wcale nie jest "underestimated" tylko szumu o tym jest pełno, flatMap wcale nie jest "most used

[moriturius]

@hbpitero: No faktycznie nie powinno się pisać o czymś co się słabo ogarnia :)

Gdybym użył .map zamiast .flatMap dostałbym w wyniku Optional> - nie do końca o to chodziło. Byłbym też wdzięczny gdybyś mi wytłumaczył do czego się .flatMap używa :)

Przykłady też słabe bo nie uciekasz od nulla (nadal w obrębie klasy używasz nulla i ofNullable)

Masz rację, ale używanie nulla w jakimś zamkniętym kontekście to zupełnie coś innego

[hbpitero]

@moriturius: Masz rację, więc tak na szybko

Musiałeś coś pomieszać w swoim kodzie, gdyż map z Optional nie dbędzie wymagać funkcji mapującej Optional na X tylko T na X, więc sytuacji z Optional> by tutaj nie było. Możemy najzwyczajniej mapować w najzwyklejszy sposób zapominając o optionalach:

book.map(Book::getAuthor).map(Author::getName).map(String::trim).map(Stirng::length).forEach(System.out::println);

Więc nie musimy uciekać z optionala poprzez .get() itp. jest on automatycznie "unwrapowany".

flatMap działa analogicznie ale właśnie jak się domyślasz, gdy mamy pozagnieżdżane

[moriturius]

Musiałeś coś pomieszać w swoim kodzie

Proponuję nie odpisywać jednak "na szybko" tylko sprawdzić swoją wiedzę i kontekst. W moich przykładach wszystkie gettery zwracają Optional. W takim układzie:

book.map(Book::getAuthor).map(Author::getName)

się nie skompiluje. A to dlatego, że jeśli getAuthor zwraca Optional to użycie prostej funkcji map sprawi, że otrzymasz Optional>. Jeśli chcesz się o to kłócić to przynajmniej najpierw napisz jakiś kod, który się skompiluje i uruchomi. Nic tutaj nie jest

[moriturius]

@hbpitero: Nie zawołałem cię wyżej, a to do ciebie ;)

[hbpitero]

@moriturius: Faktycznie mnie zaskoczyłeś, najbadziej z nie-leniwym wywołaniem map.

Nie mniej nie "promowałbym" getterów setterów i flatMap w taki sposób. A już w szczególności, aby gettery i settery zwracały inny typ niż typ atrybutu.

[moriturius]

@hbpitero: no to faktycznie niezgodne z konwencją wiec może wprowadzać w błąd