Idziecie w jakieś filozoficzne rozważania. Funkcja w programowaniu funkcyjnym jest pojęciem prawie tożsamym z definicją matematyczną. Prawie, bo jednak nie wszystkie funkcje są "pure", np. now()
, rand()
.
Program funkcyjny to w założeniu funkcja złożona np. f(g(h(x)))
, gdzie wynik h(x) jest parametrem g(), a wynik g() jest parametrem f(). Wyjątek rzucony z h() nie zostanie zwrócony jako parametr do g() i do h(). Dlatego rzucanie wyjątkami nie jest zgodne z "duchem" programowania funkcyjnego.
@piotrpo zakładając, że rzucone wyjątki są częścią return value
to nie widzę powodów dlaczego wyjątki mogą nie być pure. Zarówno mamy zachowaną czystość (ten sam wynik dla tych samych argumentów) jak i referential transparency (wykluczając oczywiście stack traces)
Ale cała dyskusja toczy się wokół wyższości Wielkanocy nad Gwiazdką either
nad throw
. Zwracanie wyjątku w postaci return value
, czyli opakowanego w either
oznacza, że funkcja zwraca wciąż tę samą strukturę, jedynie z innymi wartościami. W matematyce przecież funkcja również nie musi zwracać koniecznie liczby rzeczywistej, może być liczba złożona, tensor czy inny kwaternion.
slsy napisał(a):
@piotrpo zakładając, że rzucone wyjątki są częścią
return value
to nie widzę powodów dlaczego wyjątki mogą nie być pure. Zarówno mamy zachowaną czystość (ten sam wynik dla tych samych argumentów) jak i referential transparency (wykluczając oczywiście stack traces)
Tak, wyjątki zwrócone przez return value są zasadniczo pure.
Impure jest tylko jak są rzucone przez throw.
powoduje side-effect, więc funkcja nie jest już 'pure'
Jeżeli wyjątek powoduje site effect to return
tym bardziej go powoduje. Jeżeli wyjątek powoduje terminacje programu to tym bardziej wyjście z metody main
.
powoduje, że tracimy 'referential transparency'
Tego punktu nie łapę, można zastąpić foo()
throw new FooException()
i będzie Git. Nie można tutaj mówić że nie spełnia referential transparency.
Niestety jest to 99 wątek tego rodzaju na 4p. Moderacja powinna wziąć się do roboty i zacząć stemplować [Duplicate]
tak jak to robią na SO...
Jeżeli wyjątek powoduje site effect to return tym bardziej go powoduje.
Jak, return to normalne wyjście z funkcji i nie powoduje side effects, za to wyjątek jak najbardziej.
Tego punktu nie łapę, można zastąpić foo() throw new FooException() i będzie Git.
Co będzie git, przecież jeśli oczekujemy wyniku, np. liczby, to tracimy referential transparency, chyba, że zawsze rzucamy wyjątek.
99xmarcin napisał(a):>
Tego punktu nie łapę, można zastąpić
foo()
throw new FooException()
i będzie Git. Nie można tutaj mówić że nie spełnia referential transparency.
Nie można. Referential transparency oznacza, że możesz zamienić wywołanie funkcji przez wartość funkcji w punkcie. throw new FooException()
nie jest wartością. Nie możesz np. podstawić tego pod zmienną. Możesz podstawić samo new FeeException()
ale to już będzie działać inaczej.
Niestety jest to 99 wątek tego rodzaju na 4p. Moderacja powinna wziąć się do roboty i zacząć stemplować [Duplicate] tak jak to robią na SO...
Raczej powinniśmy pisać. Było, użyj opcji szukaj
. Dzięki temu odbudujemy popularność portalu.
@jarekr000000: Tak przeszukiwałem całe forum w poszukiwaniu odpowiedzi na swoje pytanie, ale im dłużej czytałem tym mniej byłem pewien co jest prawdą a co nie. W każdym razie dziękuję wszystkim za opinie - wybiorę sobie z nich swoją wersje prawdy.
Zarejestruj się i dołącz do największej społeczności programistów w Polsce.
Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.