Rzucanie nulli w Kotlinie

Odpowiedz Nowy wątek
2019-05-09 12:51
eL
0

W Javie żeby nie rzucać nullami i łatwiej je przetwarzać powstała klasa Optional. W Kotlinie takiej klasy nie ma i by default wszystko jest null safety. Czasami jednak zdarza się że chcemy pobrać jakąś wartość (np. z bazy) której nie ma. Oczywiście możemy rzucać Either i inne tego typu pokroju obiekty ale pytanie czy rzucanie nullem w Kotlinie ma sens? Jakby tak podejść do tematu generycznie to pewnie jest to bezsensu bo null to nadal null ale z drugiej strony w kotlinie przetwarzanie nulli w stylu np.:

    value?.let { doSomething } 

jest poniekąd podobne do tego co robimy z Optionalem w Javie (np. map).

Pytanie więc. Rzucanie nulli w Kotlinie jest akceptowalne czy raczej bee?

Pozostało 580 znaków

2019-05-12 13:14
0
jarekr000000 napisał(a):

Nie jestem tego 100% pewny. Rozpatrywane w izolacji T? jest ładniejsze od Optional<T>.
Ale fakt, że mamy jeszcze Either<E,T>, Try<T>, Future<T> i tony innych M<T> powoduje pytanie czy nie lepiej by było gdyby była składnia do obsługi dowolnych M<T> (poodstawa to tzw. do notation ).
Możliwe, że będą sobie pluć w brodę za jakiś czas.

Z drugiej strony nie jestem też pewny, że wybrali złe rozwiązanie. Po prostu widzę problem, ale nie wiem jak z tego wybrnąć dobrze i praktycznie. Ich rozwiązanie jakoś działa, ale poza obsługą nulli z javy i framorków nie stosuję T? tylko Option<T>. Co więcej nie mam przekonania, że dobrze robię...
(ale drażnią mnie trochę takie wyjątki w języku).

Nie znam za bardzo kotlina, ale zastanawia mnie co daje w tej sytuacji używanie języka który buduje tone abstrakcji nad null-safety po to tylko żeby babrać się dalej z klasami typu Option/Optional ? Skoro i tak jest jakiś tam impakt na wydajności (?) ? Im więcej słyszę o kotlinie tym bardziej zaczyna mi się wydawać ze to kolejna modna rzecz w IT, na którą jest chwilowe parcie na szkło, a za rok/dwa nikt juz o tym nie będzie pamiętać a java będzie miała się dobrze? Jak bardzo warto jest przenieść się do języka "nowoczesnego" po to żeby sprzedać javowe dobrze znane problemy na kotlinowe?

Podsumowując jak juz używamy Option to jedyny zysk z kotlina to gettery/settery i trochę zwięźlejsza składnia tak ? Hmm to nie wiem czy nie wole lomboka i javy, przynajmniej za pół roku nikt nie będzie musiał przepisywać tych aplikacji.

edytowany 2x, ostatnio: Interpod, 2019-05-12 13:15

Pozostało 580 znaków

2019-05-12 13:36
3
Interpod napisał(a):

Nie znam za bardzo kotlina, ale zastanawia mnie co daje w tej sytuacji używanie języka który buduje tone abstrakcji nad null-safety po to tylko żeby babrać się dalej z klasami typu Option/Optional ?

O jakiej tonie abstrakcji piszesz? Znak zapytania przy typie, to chyba najprostsze rozróżnienie jakie może być w przeciwieństwie do Option, który już jest jakąś abstrakcją.

Skoro i tak jest jakiś tam impakt na wydajności (?) ?

Nie ma. A jeśli komuś zależy na tych nanosekundach, to może wyłączyć podczas kompilacji, żeby nie były dodawane checki dla nulli w publicznych metodach.

https://medium.com/@BladeCode[...]dden-costs-part-2-324a4a50b70

Jak bardzo warto jest przenieść się do języka "nowoczesnego" po to żeby sprzedać javowe dobrze znane problemy na kotlinowe?

A jakie problemy przenosisz z Javy do Kotlina korzystając z Option?

Podsumowując jak juz używamy Option to jedyny zysk z kotlina to gettery/settery i trochę zwięźlejsza składnia tak? Hmm to nie wiem czy nie wole lomboka i javy, przynajmniej za pół roku nikt nie będzie musiał przepisywać tych aplikacji.

Zależy, co masz na myśli. Bo pod "trochę zwięźlejszą składnią" może kryć się wszystko.

  • delegacje
  • val, var
  • inferencja typów
  • data klasy
  • destrukcje
  • sealead klasy
  • internal
  • korutyny
  • wbudowana składnia dla funkcji
  • funkcje i właściwości rozszerzające
  • typealias (to trochę bieda, ale patrz punkt niżej)
  • inline klasy
  • wsparcie dla wielu platform
  • wyrażenia zamiast intrukcji
  • parę innych rzeczy do lukru składniowego

Lombok poza data class i val, var niczego z tej listy nie oferuje.

edytowany 3x, ostatnio: Michał Sikora, 2019-05-12 13:39
Dodałbym jeszcze when statement do listy. Wreszcie można wsadzić wyrażenia do czegoś, co przypomina switch zamiast dziobać kaskady if...else if.......else if.....else... wszędzie, gdzie nie da się sprowadzić warunku do x == 3. - superdurszlak 2019-05-12 13:52
i jeszcze dużo praktycznych rzeczy w stylu smart cast (ten smart cast to raczej w chorych miejscach, ale zawsze). - jarekr000000 2019-05-12 21:42

Pozostało 580 znaków

2019-05-12 21:36
2
Interpod napisał(a):

Nie znam za bardzo kotlina, ale zastanawia mnie co daje w tej sytuacji używanie języka który buduje tone abstrakcji nad null-safety po to tylko żeby babrać się dalej z klasami typu Option/Optional ? Skoro i tak jest jakiś tam impakt na wydajności (?)

Impakt na wydajności jest - w microenchmarkach. Trzeba mieć pecha, żeby zobaczyć na produkcji. Tym niemniej, bezpieczeństwo kosztuje, trzeba wybrać czasem co ważniejsze.
Jak kiedyś wyjdzie mi, że w jakimś kluczowym miejscu Option mi spowalnia to go z radością tam przepiszę na null. Na razie nawe nie byłem blisko.
Będzie jeszcze mniejszy narzut Optiona jak wprowadzą ValueTypes (Valhalla).

Podsumowując jak juz używamy Option to jedyny zysk z kotlina to gettery/settery i trochę zwięźlejsza składnia tak ? Hmm to nie wiem czy nie wole lomboka i javy, przynajmniej za pół roku nikt nie będzie musiał przepisywać tych aplikacji.

Pomijając już całego lomboka, którego najważniejsze sensowne zastosowanie widzę w procesie pozbywania się jedzenia z żołądka. To jeśli rzeczywiście używasz go głównie do setterów i getterów to naprawdę współczuje tym co za rok - dwa nie będą mogli przepisać twoich aplikacji. W kotlinie chyba tych setterów to użyłem raz, bo z durnym frameworkiem pracowałem.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 4x, ostatnio: jarekr000000, 2019-05-13 09:10
Mógłbyś coś więcej napisać o Lomboku? Właśnie planowałem z niego skorzystać do generowania equals i hashCode, ale teraz to nie wiem :P - Potat0x 2019-05-12 22:17
Do generowania equals i hashCode możesz stosować. Ale w zespole to sie szybko rozrasta. Możesz dostać heavy lombokowy kod, który będzie dość wymiotnie wyglądał. - jarekr000000 2019-05-13 05:16
Dokładnie. A prawdziwy cyrk zaczyna się, gdy trzeba pogodzić jakoś lomboka z innym cudem typu mapstruct i w końcu widzisz klasy z 3 polami i 8 annotacjami. Lombok ma kilka fajnych featurów (@Value, @Builder), ale najlepiej stosować z umiarem. - MW600 2019-05-13 19:45

Pozostało 580 znaków

2019-05-15 10:02
V-2
0
danek napisał(a):

Kotlinowe ? to po prostu odpowiednik Optional z javy, tylko lepsze.

Nie całkiem. Np. w RxJavie (2.x) nie mogę zastosować typu Observable<Something?>. Zgodnie ze specyfikacją Reactive Streams, strumienie nie przyjmują nulli w ogóle. Mogę więc być zmuszony do stworzenia jakiegoś własnego wrappera - zaimprowizowanego Optionala - jeśli nie jestem w stanie zlikwidować nullowalności (bo np. źródło danych, które czasem bywają nullami, leży poza moim kodem).

Inaczej jest w Swifcie, gdzie typy "nullowalne" są, tak naprawdę, słodzikiem składniowym na Optionale właśnie, a nie prawdziwymi nullami. Tyle, że twórcy Swifta nie musieli się martwić interoperowalnością z Javą.


Nie ma najmniejszego powodu, aby w CV pisać "email" przed swoim adresem mailowym, "imię i nazwisko" przed imieniem i nazwiskiem" ani "zdjęcie mojej głowy od przedniej strony" obok ewentualnego zdjęcia.
edytowany 1x, ostatnio: V-2, 2019-05-15 10:02

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0