Czy da się uniknać DI?

2
._. napisał(a):

No ale w dotnecie mogę sobie zwrócić default(int) to po co mi jakiś ekstra typ jak optional ?
Jak chce mieć readera to robie sobie klasę z generycznym typem i wewnątrz klasy tworzę instancje z tego typ'a po refleksji.
Zamiast nulowych ifów mogę użyć znaku zapytania.

To tak dla zasady mam używać, chain'nowych odpowiedników.?

No nie wiem czy to takie przydatne jest.

Ale zwrócenie default(int) też nic nie mówi. Żyjemy w takich czasach, że nie trzeba zwracać nic nie mówiących liczb, a można wykorzystywać system typów i struktury danych. Jeśli funkcja może zwrócić wartość ale nie musi, to Optional wprost o tym mówi - w przeciwieństwie do jakiejś domyślnej wartości typu 0. Patrząc na sygnaturę def blabla(...): Option[Int] oraz na def blabla(...): Int, w której z nich możesz mieć od razu pewność, że funkcja nie musi zwrócić wyniku? Dodatkowo, czemu akurat default(int) ma być jakąś magiczną wartością zwracaną z funkcji? A co jeśli wartość default(int) znajduje się w dziedzinie możliwych do zwrócenia wartości przez funkcję?

Nie wiem jak w dotnecie, ale przykładowo w Javie refleksji powinno się unikać na tyle na ile to jest możliwe, a używać jej jak już nie ma na nic innego ratunku. Domyślam się, że w dotnecie jest podobnie aczkolwiek mogę się tu mylić. Sam Reader służy do tego, aby móc skomponować kilka "klocków" (funkcji) jednocześnie abstrahując od tego, że każda z nich wymaga tych samych zależności.

Nie znam się na dotnecie, ale zgodnie z tym co znalazłem '?.' wykonuje operacje jeśli coś nie jest nullem, w innym przypadku zwraca nulla. To nie jest to samo co robi Option. Jeśli jakaś wartość jest zawarta wewnątrz kontekstu Option, to możesz używać 'map', 'flatMap' czy innych operacji tak, aby operować na wartości wewnątrz. Po wykonaniu wszystkich operacji koniec końców zwracany jest i tak Option (kontekst się nie zmienia) i potencjalny brak wyniku musisz jakoś obsłużyć. W przeciwieństwie do zwracania nulli znacznie to eliminuje możliwość (a praktycznie niweluje do 0) wystąpienia NPE.

0

Patrząc na sygnaturę def blabla(...): Option[Int] oraz na def blabla(...): Int, w której z nich możesz mieć od razu pewność, że funkcja nie musi zwrócić wyniku?

public int GetGroupNumberOfUserOrDefault()
{
     return new Test()?.User?.Group?.Number ?? default;
}

A teraz masz pewność.?

A co jeśli wartość default(int) znajduje się w dziedzinie możliwych do zwrócenia wartości przez funkcję

A co w tedy zrobisz monadą? :-|

Nie wiem jak w dotnecie, ale przykładowo w Javie refleksji powinno się unikać na tyle na ile to jest możliwe, a używać jej jak już nie ma na nic innego ratunku. Domyślam się, że w dotnecie jest podobnie aczkolwiek mogę się tu mylić. Sam Reader służy do tego, aby móc skomponować kilka "klocków" (funkcji) jednocześnie abstrahując od tego, że każda z nich wymaga tych samych zależności.

Broń boże, przecież cały Spring, Contenery, Beany, Aspekty one nie bazują na refleksji.

Nie znam się na dotnecie, ale zgodnie z tym co znalazłem '?.' wykonuje operacje jeśli coś nie jest nullem, w innym przypadku zwraca nulla. To nie jest to samo co robi Option. Jeśli jakaś wartość jest zawarta wewnątrz kontekstu Option, to możesz używać 'map', 'flatMap' czy innych operacji tak, aby operować na wartości wewnątrz. Po wykonaniu wszystkich operacji koniec końców zwracany jest i tak Option (kontekst się nie zmienia) i potencjalny brak wyniku musisz jakoś obsłużyć. W przeciwieństwie do zwracania nulli znacznie to eliminuje możliwość (a praktycznie niweluje do 0) wystąpienia NPE.

Ale żeby to zrobić ja niepotrzebuje chain'a na funkcjach ani flatMapa.

0
._. napisał(a):

Patrząc na sygnaturę def blabla(...): Option[Int] oraz na def blabla(...): Int, w której z nich możesz mieć od razu pewność, że funkcja nie musi zwrócić wyniku?

public int GetGroupNumberOfUserOrDefault()
{
     return new Test()?.User?.Group?.Number ?? default;
}

A teraz masz pewność.?

Nie mam żadnej o czym najlepiej świadczy fakt, że musiałeś pokazać implementację metody. Co zrobisz jeśli groupNumber jest taki sam jak default? Obsłużysz to jako błąd? Czym w ogóle jest ten default? Jest to błąd czy poprawna wartość jaką może przyjmować group number? Pojawia się wiele pytań, których można uniknąć wykorzystując typy, na przykład tworząc ADT. Jeśli miałbym pisać tego typu funkcję to wolałbym sygnaturę public Int getGroupNumberOfUserOrDefualt(Int default) - przynajmniej wiadomo skąd bierze się default, nie mniej sam bym pewnie takiej funkcjonalności tak nie napisał.

A co jeśli wartość default(int) znajduje się w dziedzinie możliwych do zwrócenia wartości przez funkcję

A co w tedy zrobisz monadą? :-|

Nie muszę nic robić bo wiem, że brak wyniku jest oznaczony przez None, a nie przez randomową liczbę.

Nie wiem jak w dotnecie, ale przykładowo w Javie refleksji powinno się unikać na tyle na ile to jest możliwe, a używać jej jak już nie ma na nic innego ratunku. Domyślam się, że w dotnecie jest podobnie aczkolwiek mogę się tu mylić. Sam Reader służy do tego, aby móc skomponować kilka "klocków" (funkcji) jednocześnie abstrahując od tego, że każda z nich wymaga tych samych zależności.

Broń boże, przecież cały Spring, Contenery, Beany, Aspekty one nie bazują na refleksji.

W kodzie który ja piszę nie używam refleksji albo staram się tego nie robić. Frameworki w wielu językach do poprawnego działania muszą ją wykorzystywać, ale ja jako użytkownik już nie.

Nie znam się na dotnecie, ale zgodnie z tym co znalazłem '?.' wykonuje operacje jeśli coś nie jest nullem, w innym przypadku zwraca nulla. To nie jest to samo co robi Option. Jeśli jakaś wartość jest zawarta wewnątrz kontekstu Option, to możesz używać 'map', 'flatMap' czy innych operacji tak, aby operować na wartości wewnątrz. Po wykonaniu wszystkich operacji koniec końców zwracany jest i tak Option (kontekst się nie zmienia) i potencjalny brak wyniku musisz jakoś obsłużyć. W przeciwieństwie do zwracania nulli znacznie to eliminuje możliwość (a praktycznie niweluje do 0) wystąpienia NPE.

Ale żeby to zrobić ja niepotrzebuje chain'a na funkcjach ani flatMapa.

Zależy co chcesz zrobić. Jeśli chcesz mieć wszędzie sprawdzenia if (x == null) to nie trzeba nic używać. Gorzej jak w jakimś miejscu zapomnisz i wyjdzie to dopiero w runtimie

0

Nie mam żadnej o czym najlepiej świadczy fakt, że musiałeś pokazać implementację metody. Co zrobisz jeśli groupNumber jest taki sam jak default? Obsłużysz to jako błąd? Czym w ogóle jest ten default? Jest to błąd czy poprawna wartość jaką może przyjmować group number? Pojawia się wiele pytań, których można uniknąć wykorzystując typy, na przykład tworząc ADT. Jeśli miałbym pisać tego typu funkcję to wolałbym sygnaturę public Int getGroupNumberOfUserOrDefualt(Int default) - przynajmniej wiadomo skąd bierze się default, nie mniej sam bym pewnie takiej funkcjonalności tak nie napisał.

Naprawdę? to dziwne, bo w .Net'cie często się pojawiają tego typu funkcje jak FirstOrDefault, ElementAtOrDefault. Może przeczytaj w doc od ms co znaczy default?

Nie muszę nic robić bo wiem, że brak wyniku jest oznaczony przez None, a nie przez randomową liczbę.

A to muszę cię pochwalić. Super!

W kodzie który ja piszę nie używam refleksji albo staram się tego nie robić. Frameworki w wielu językach do poprawnego działania muszą ją wykorzystywać, ale ja jako użytkownik już nie.

Masz rację nie używaj refleksji od razu coś zepsujesz, lepiej żeby framework robił to za ciebie.

Zależy co chcesz zrobić. Jeśli chcesz mieć wszędzie sprawdzenia if (x == null) to nie trzeba nic używać. Gorzej jak w jakimś miejscu zapomnisz i wyjdzie to dopiero w runtimie

Wiesz co... Wy Javowcy ciągle coś odkrywacie jeszcze nie dawno był stream i var. Ja nie piszę w Javie, żebym musiał if null wszędzie robić, jeśli nie używam "optionala".

1
._. napisał(a):

Naprawdę? to dziwne, bo w .Net'cie często się pojawiają tego typu funkcje jak FirstOrDefault, ElementAtOrDefault. Może przeczytaj w doc od ms co znaczy default?

To że coś jest gdzieś w jakiś sposób napisane nie znaczy, że jest wybitne. Przykład: Java.util.Date. Tak samo nie znaczy, że w niektórych przypadkach nie ma sensu, szkoda tylko, że odpowiadasz na jedna rzecz, a 5 pytań leży bez odpowiedzi.

A to muszę cię pochwalić. Super!

Dziękuję.

Masz rację nie używaj refleksji od razu coś zepsujesz, lepiej żeby framework robił to za ciebie.

Raczej, nie używaj refleksji a może ktoś poza Tobą zrozumie co chciałeś zrobić. Ja lubię pisać kod który w przyszłości jest łatwo utrzymać, Ty nie musisz.

Wiesz co... Wy Javowcy ciągle coś odkrywacie jeszcze nie dawno był stream i var. Ja nie piszę w Javie, żebym musiał if null wszędzie robić, jeśli nie używam "optionala".

No cóż, średnio trafione, bo pracuję na JVM ale nie w Javie. To dla Ciebie, dotnetowca, polecam poczytać o F#. Też dużo fajnych rzeczy wymyślili.

Podziękuję za dalszą rozmowę bo odpowiadasz jedynie na wybrane i "wygodne" pytania, a do tego dokladasz specyficzny język ataku, ale to pewnie my, javowcy tacy wrażliwi jesteśmy ;)

0

5 pytań leży bez odpowiedzi.

Nie chce mi się odpowiadać na durne pytania bez sensu. Jak to czym jest default, albo co jak GroupNumber jest ten sam co default.....

Raczej, nie używaj refleksji a może ktoś poza Tobą zrozumie co chciałeś zrobić. Ja lubię pisać kod który w przyszłości jest łatwo utrzymać, Ty nie musisz.

Tak fashion desing jest bardzo utrzymywalny. Tak naprawdę to cały czas używasz refleksji samo serializowanie do jsona i tp. opiera się na refleksji. A że sam nie potrafisz zrobić coś sensownego z tym mechanizmem to twój problem.

No cóż, średnio trafione, bo pracuję na JVM ale nie w Javie. To dla Ciebie, dotnetowca, polecam poczytać o F#. Też dużo fajnych rzeczy wymyślili.
Podziękuję za dalszą rozmowę bo odpowiadasz jedynie na wybrane i "wygodne" pytania, a do tego dokladasz specyficzny język ataku, ale to pewnie my, javowcy tacy wrażliwi jesteśmy ;)

To taki mój subtelny sposób wyrażenia, że nie chce mi się rozmawiać.... Wiem, że jestem wredny, nie przejmuj się tym.

A w czym piszesz, jeśli można wiedzieć.?

0
._. napisał(a):

Tak fashion desing jest bardzo utrzymywalny. Tak naprawdę to cały czas używasz refleksji samo serializowanie do jsona i tp. opiera się na refleksji. A że sam nie potrafisz zrobić coś sensownego z tym mechanizmem to twój problem.

Refleksja jest słabo utrzymywalna (zmienia się wersja i okazuje się, że pod spodem sa inne klasy i inne pola), ale kompikator złego słowa nie powie.... Dodatkowo utrudnia optymalizację kodu wynikowego (bo biedny kompilator nie wie, czy można pole wywalić, bo nikt się wprost do pola nie dobiera, ale może jest to robione refleksją ).

W Scali (na JVM) w nowszych bibliotekach już prawie nie używa się refleksji, starsze biblioteki są poprawiane żeby nie używać. Np. nowsze biblioteki nie używają refleksji przy (de)serializacji json.
Ot, okazało się, że można lepiej.

2
._. napisał(a):

No ale w dotnecie mogę sobie zwrócić default(int) to po co mi jakiś ekstra typ jak optional ?

"Po co budować rakiety, skoro całe życie wszędzie jeździłem rowerem?"

DisQ napisał(a):

Nie wiem jak w dotnecie, ale przykładowo w Javie refleksji powinno się unikać na tyle na ile to jest możliwe, a używać jej jak już nie ma na nic innego ratunku. Domyślam się, że w dotnecie jest podobnie aczkolwiek mogę się tu mylić.

Ogólnie w .NET istnieje trochę róznych zabobonów dotyczących refleksji, większość z nich pewnie została skopiowana z Javy. ;)

jarekr000000 napisał(a):

Refleksja jest słabo utrzymywalna (zmienia się wersja i okazuje się, że pod spodem sa inne klasy i inne pola)

To nie powinien być żaden problem dla bezpiecznie napisanego kawałka kodu, abstrahując już od tego, czy korzysta z refleksji czy nie.

0

"Po co budować rakiety, skoro całe życie wszędzie jeździłem rowerem?"

A ty co, używasz optionala ? :-|

0
somekind napisał(a):

To nie powinien być żaden problem dla bezpiecznie napisanego kawałka kodu, abstrahując już od tego, czy korzysta z refleksji czy nie.

W zasadzie prawda. Z dodatkowym zastrzeżeniem, że jeśli kod korzysta z refleksji to, z automatu, nie jest bezpiecznie napisany.

0
jarekr000000 napisał(a):

W zasadzie prawda. Z dodatkowym zastrzeżeniem, że jeśli kod korzysta z refleksji to, z automatu, nie jest bezpiecznie napisany.

Oczywiście, to nie jest łatwe, trzeba wiele rzeczy sprawdzać i dodać sporo obsługi błędów, ale to nie znaczy, że jest niebezpieczny. Ja jakoś daję radę pisać tak, że nie mam żadnych niespodzianek.
No chyba, że ktoś faktycznie próbuje refleksją ustawiać wartości pól w kodzie biznesowym. Ale to już nie wina refleksji tylko rodziców.

0
somekind napisał(a):

Oczywiście, to nie jest łatwe, trzeba wiele rzeczy sprawdzać i dodać sporo obsługi błędów, ale to nie znaczy, że jest niebezpieczny. Ja jakoś daję radę pisać tak, że nie mam żadnych niespodzianek.
No chyba, że ktoś faktycznie próbuje refleksją ustawiać wartości pól w kodzie biznesowym. Ale to już nie wina refleksji tylko rodziców.

Pytanie własciwe brzmi - do czego ta refleksja jest używana/ potrzebna? Masz jakiś przypadek ? W javie np. niestety czasem jest potrzebna, ale to tylko wina słabości Javy.

0
somekind napisał(a):

"Po co budować rakiety, skoro całe życie wszędzie jeździłem rowerem?"

Niektórzy lubią opakowywać nula w None i udawać, że nie istnieje a zamiast ifa użyć metody, która robi to samo. Nie widzę w tym żadnej rakiety ani fajerwerków. Zaraz będą wciskać, że tylko w legacy kod metoda zwraca nula, a potem zaczną opakowywać puste wartości jak string.empty po to żeby je sprawdzić w optionalu. Bez sensu.

7

I tak o to temat DI zszedł na wojnę Option vs null :)

@._.
W Option wcale nie chodzi o to, że jest to łatwiejsze w używaniu, szybsze, cokolwiek. Jedyny plus jest taki, że użytkownik funkcji, która zwraca Option ma jawnie podane, że tej wartości może nie być. Tylko tyle i aż tyle. Tak samo jak zwracasz z metody jakieś DTO to masz jawnie podane co zwracasz, jakie pola. I to jest cały ten trick, że jeśli już korzystamy z jakiegoś systemu typów to można go równie dobrze użyć do zasygnalizowania takiej sytuacji, że funkcja nic nie zwróci.

Równie dobrze, możnaby wszędzie używać dynamicznego typowania i jakimś aspektem sprawdzać czy nie poleciał exception, tylko komu by się chciało tyle debuggować? Nawet języki dynamicznie typowane wprowadzają type annotations bo hej! ludzie odkryli, że tak mniej czasu spędzają nad dochodzeniem, czemu coś gdzieś się posypało, a więcej na kodzeniu :)

BTW. W C# można nawet używac linq query syntax do obsługi optionali (działa mniej więcej jak for-comprehension w scali) i nawet wygląda to przyjemnie.

Readera/Try/Innych rzeczy na M i tak nikt w C#/Javie nie użyje (nawet w scali jest zbyt dużo zabawy z tym, więc większość olewa).

Wracając do wątku, to generalnie można uniknąć wszystkich stosowanych praktyk na świecie, a w ogóle to jeszcze można pisać aplikacje enterprise w assembly. Tylko po co?

0
n0name_l napisał(a):

Readera/Try/Innych rzeczy na M i tak nikt w C#/Javie nie użyje (nawet w scali jest zbyt dużo zabawy z tym, więc większość olewa).

Nie zauważyłem edit'a więc zostawiam sam kawałek o Scali :)

Co do samej Scali to będę się kłócić :) Niektóre monady są używane bo są wbudowane w język (Either, Option, Try czy Future który nie jest najlepszym przykładem bo nie przestrzega praw). Może nie każdy wie że z nich korzysta, ale sam syntax sugar w for'ach sprawia, że są wykorzystywane. Dodatkowo, dość spora część powszechnie używanych bibliotek wykorzystuje catsy czy inne ScalaZ'y więc wymuszają jakąś integrację z nimi (np. https://github.com/tpolecat/doobie)

0
n0name_l napisał(a):

Readera/Try/Innych rzeczy na M i tak nikt w C#/Javie nie użyje (nawet w scali jest zbyt dużo zabawy z tym, więc większość olewa).

Pomijając scalę, gdzie używam ScalaZ. Nawet w Javie mam nagminnie Either, Try (zrypany tak samo jak Scalowy), Option, Future. Można je zaliczyć do rzeczy na M.

6

robienie if(... == null) ... w javie i twierdzenie ze to na to samo wychodzi co optional to jeden z objawow zacofania programistycznego, dodatkowy bonus - motywowanie tego dbaloscia o wydajnosc ;) raczej kwestia bezdyskusyjna, niemniej czasem ludzie z 10+ doswiadczenia potrafia twierdzic ze null'e latajace po kodzie biznesowym sa ok co jest po prostu przykre.
co do samego tematu - brak DI ma sens np w prostych zadaniach (typu spoj), w normalnym kodzie juz przy paru klasach robi sie nietestowalne dziadostwo

1

niemniej czasem ludzie z 10+ doswiadczenia potrafia twierdzic ze null'e latajace po kodzie biznesowym sa ok co jest po prostu przykre

Bo ci ludzie są pragmatyczni w przeciwieństwie do ciebie.

6
._. napisał(a):

Bo ci ludzie są pragmatyczni w przeciwieństwie do ciebie.

masz troche racji z tym pragmatyzmem. podrzedni programisci rzeczywiscie musza sobie robic job security w ten sposob, tzn tworzyc dziurawy kod i potem go w nieskonczonosc poprawiac :)
dochodzi do tego jeszcze reakcja alergiczna na sugestie uzywania dobrych praktyk, to by byla skaza na honorze gdyby sie przyznac ze do tej pory robilo sie fuszerke...

1
katelx napisał(a):

robienie if(... == null) ... w javie i twierdzenie ze to na to samo wychodzi co optional to jeden z objawow zacofania programistycznego, dodatkowy bonus - motywowanie tego dbaloscia o wydajnosc ;) raczej kwestia bezdyskusyjna, niemniej czasem ludzie z 10+ doswiadczenia potrafia twierdzic ze null'e latajace po kodzie biznesowym sa ok co jest po prostu przykre.
co do samego tematu - brak DI ma sens np w prostych zadaniach (typu spoj), w normalnym kodzie juz przy paru klasach robi sie nietestowalne dziadostwo

Kiedyś co wersja JDK byłem podekscytowany nowościami, ale z czasem mi przeszło i bez emocji patrzę na to czy pętla jest tak, siak, czy jej nie ma. Fajnie być na czasie, ale
gdzie ta wartość dodana pomiędzy Optionalem, a if... ? :-) Bo zdaje się o to chodzi @._. i osobiście podoba mi się próba spojrzenia na coś krytycznie.

Co nam daje nowa składnia?

  • medal "Jestem na czasie" (i w entuzjazmie będę walił Optionalami gdzie się tylko da...)
  • krótszy kod (ale czy krótszy kod zawsze jest czytelniejszy?)

Nie piszę tego złośliwie, ale nazywajmy korzyści po imieniu, bez oceniania typu 'zacofany', 'nie warty dyskusji', 'oczywisty' itd.

4
yarel napisał(a):

Co nam daje nowa składnia?

  • medal "Jestem na czasie" (i w entuzjazmie będę walił Optionalami gdzie się tylko da...)
  • krótszy kod (ale czy krótszy kod zawsze jest czytelniejszy?)

W mojej opinii Optionale dają:

  • Nałożenie constraintu w systemie typów - kompilator staje się bardziej pomocny
  • Możliwość wywnioskowania co zostanie zwrócone przez funkcję jedynie po sygnaturze
  • Brak NPE
  • Możliwość pisania bardziej generycznego kodu
  • Narzucenie na użytkowniku obsługi pustej wartości
  • "Fail-fast"

I pewnie kilka innych rzeczy o których aktualnie nie pomyślałem

1
DisQ napisał(a):
yarel napisał(a):

Co nam daje nowa składnia?

  • medal "Jestem na czasie" (i w entuzjazmie będę walił Optionalami gdzie się tylko da...)
  • krótszy kod (ale czy krótszy kod zawsze jest czytelniejszy?)

W mojej opinii Optionale dają:

  • Nałożenie constraintu w systemie typów - kompilator staje się bardziej pomocny
  • Możliwość wywnioskowania co zostanie zwrócone przez funkcję jedynie po sygnaturze
  • Brak NPE
  • Możliwość pisania bardziej generycznego kodu
  • Narzucenie na użytkowniku obsługi pustej wartości
  • "Fail-fast"

I pewnie kilka innych rzeczy o których aktualnie nie pomyślałem

Acha, tak... bez optionala to wcześniej nie było możliwe....

0
._. napisał(a):

Acha, tak... bez optionala to wcześniej nie było możliwe....

Po co używasz C#? Przecież w Assembly mogłeś zrobić dokładnie to samo

0

Co nam daje nowa składnia?

@n0name_l napisal glowna zalete, a @DisQ z reszta wiec skupie sie na zlosliwosciach :D

  • medal "Jestem na czasie" (i w entuzjazmie będę walił Optionalami gdzie się tylko da...)

nikt nie twierdzi zeby walic gdzie sie da

  • krótszy kod (ale czy krótszy kod zawsze jest czytelniejszy?)

nikt nie powiedzial ze krocej == czytelniej

oczywiste ze z optionalami mozna przesadzic, jak z wszystkim, ale to zaden argument zeby zostawac przy nullach :)

0
katelx napisał(a):
._. napisał(a):

Bo ci ludzie są pragmatyczni w przeciwieństwie do ciebie.

masz troche racji z tym pragmatyzmem. podrzedni programisci rzeczywiscie musza sobie robic job security w ten sposob, tzn tworzyc dziurawy kod i potem go w nieskonczonosc poprawiac :)
dochodzi do tego jeszcze reakcja alergiczna na sugestie uzywania dobrych praktyk, to by byla skaza na honorze gdyby sie przyznac ze do tej pory robilo sie fuszerke...

Oczywiście jak typ zwraca default, czyli np. null to jest to problem bezpieczeństwa. :-|

1
yarel napisał(a):
katelx napisał(a):

robienie if(... == null) ... w javie i twierdzenie ze to na to samo wychodzi co optional to jeden z objawow zacofania programistycznego, dodatkowy bonus - motywowanie tego dbaloscia o wydajnosc ;) raczej kwestia bezdyskusyjna, niemniej czasem ludzie z 10+ doswiadczenia potrafia twierdzic ze null'e latajace po kodzie biznesowym sa ok co jest po prostu przykre.
co do samego tematu - brak DI ma sens np w prostych zadaniach (typu spoj), w normalnym kodzie juz przy paru klasach robi sie nietestowalne dziadostwo

Kiedyś co wersja JDK byłem podekscytowany nowościami, ale z czasem mi przeszło i bez emocji patrzę na to czy pętla jest tak, siak, czy jej nie ma. Fajnie być na czasie, ale
gdzie ta wartość dodana pomiędzy Optionalem, a if... ? :-) Bo zdaje się o to chodzi @._. i osobiście podoba mi się próba spojrzenia na coś krytycznie.

Co nam daje nowa składnia?

  • medal "Jestem na czasie" (i w entuzjazmie będę walił Optionalami gdzie się tylko da...)
  • krótszy kod (ale czy krótszy kod zawsze jest czytelniejszy?)

Nie piszę tego złośliwie, ale nazywajmy korzyści po imieniu, bez oceniania typu 'zacofany', 'nie warty dyskusji', 'oczywisty' itd.

Pomyślmy, możliwośc łatwego oznaczenia i powiedzenia komuś innemu: Ej ziomeczku, ta metoda może zwrócic pusty rezultat :) O flat, flatMap itd. nie wspomne...
PS. W Scalii to było od 2004 więc super nowość ten Option :D

0

oczywiste ze z optionalami mozna przesadzic, jak z wszystkim, ale to zaden argument zeby zostawac przy nullach :)

Przecież ty robisz to samo z optionalem sprawdzasz czy coś jest nulem, tylko inaczej. Ja mogę sobie do tego zrobić zwyły extension method. Jak widać sama jesteś zacofana.

Poza tym to chory pomysł w języku obiektowym wywalać sprawdzenie nula poza metodę. Na zasadzie

Get().Mach(Fail: , Erro: )
1
DisQ napisał(a):

...

W mojej opinii Optionale dają:

  • Nałożenie constraintu w systemie typów - kompilator staje się bardziej pomocny

Pełna zgoda.

  • Możliwość wywnioskowania co zostanie zwrócone przez funkcję jedynie po sygnaturze

Ja defensywnie zakładam, że może być null i zastanawiam się w jakich sytuacjach ten null może się pojawić i co z nim zrobić (ot taki nawyk z języków, gdzie "optionale są standardem" - np. C :P)

  • Brak NPE

Czyli jak nie mamy NPE, to nie dowiemy się szybko o błędzie, tylko po cichu będziemy pracować z pustymi wartościami? :-) Czy to trochę nie kłóci się z "fail-fastem", chyba, że masz coś innego na myśli jako "fail-fast"?

  • Możliwość pisania bardziej generycznego kodu

Generycznego w sensie oderwania od typów?

  • Narzucenie na użytkowniku obsługi pustej wartości

I co ten user ma zrobić z pustą wartością? Tak jakby dostał nulla, tylko że słodsza składnia?

  • "Fail-fast"

W jakim sensie "fail-fast" ?

0
yarel napisał(a):
  • Możliwość wywnioskowania co zostanie zwrócone przez funkcję jedynie po sygnaturze

Ja defensywnie zakładam, że może być null i zastanawiam się w jakich sytuacjach ten null może się pojawić i co z nim zrobić (ot taki nawyk z języków, gdzie "optionale są standardem" - np. C :P)

Jeśli dostałbym NPE podczas wywoływania metod na Optionie to zastanowiłbym się co poszło nie tak i poprawił to w taki sposób, aby nie było takiej możliwości ;)

  • Brak NPE

Czyli jak nie mamy NPE, to nie dowiemy się szybko o błędzie, tylko po cichu będziemy pracować z pustymi wartościami? :-) Czy to trochę nie kłóci się z "fail-fastem", chyba, że masz coś innego na myśli jako "fail-fast"?

Option przedstawia dwie możliwości -> brak wartości bądź wartość. Jeśli jest wykorzystywany zgodnie z założeniem (map, flatMap itd.) to w przypadku braku wartości kolejne mapy/flatMapy nie będą wykonywane. Mniej więcej to rozumiem przez "fail-fast". Oczywiście pusta wartość (np. w Stringu "") nadal może stanowić jakąś wartość i jeśli wiesz że tak jest to należy to mieć na uwadze (metody typu filter itd.)

  • Możliwość pisania bardziej generycznego kodu

Generycznego w sensie oderwania od typów?

Można pójść krok dalej i mówić o kodzie generycznym na poziomie efektów - Option, Either, Future, IO itd.

  • Narzucenie na użytkowniku obsługi pustej wartości

I co ten user ma zrobić z pustą wartością? Tak jakby dostał nulla, tylko że słodsza składnia?

Obsłużyć zgodnie z logiką biznesową - czasami przypisać wartość domyślną, a innym razem zwrócić błąd na UI że coś poszło nie tak.

  • "Fail-fast"

W jakim sensie "fail-fast" ?

Option[String](null).flatMap(x => if (x.contains("WORLD") Some(x) else None).map(_.toUpperCase)
W powyższym przypadku żadna z operacji nie zostanie wykonana ponieważ Option już na początku reprezentuje brak wartości.
Option[String]("hello").flatMap(x => if (x.contains("WORLD") Some(x) else None).map(_.toUpperCase)
W powyższym przypadku wykona się flatMap, ale map już nie. Wydaje mi się że przykłady to przedstawiają lepiej niż mógłbym napisać.

0
DisQ napisał(a):

Ja defensywnie zakładam, że może być null i zastanawiam się w jakich sytuacjach ten null może się pojawić i co z nim zrobić (ot taki nawyk z języków, gdzie "optionale są standardem" - np. C :P)

Tylko po co wrzucać wszędzie ify skoro można nie?

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