@TomRiddle:
Filozoficzne pytanie :] Jeśli robię coś co jest typowo obiektowe, czyli ma stan i zachowanie, to zwykle robię to w oddzielnym pliku. Z drugiej strony takie DTOsy nieraz pakuję hurtem w jednym pliku, bo pojedyncza case classa w Scali jest krótka i zwykle nie opłaca się robić osobnego pliku. Trzeba tylko pamiętać, żeby mieć sensowny namespace, a nie naśmiecone dziesiątki typów bezpośrednio w jednym package. Z tym, że DTOsy to przecież nie są pełnoprawne obiekty. Nigdy nie dążyłem do pisania w 100% obiektowo, więc nie mam z tym doświadczeń.
@KamilAdam
Hmm, a czy jest jakiś praktyczny język w 100% funkcyjny? Czy monada IO jest 100% funkcyjna? Efekt uboczny opakowany w monadę IO dalej jest efektem ubocznym, tyle że wykonywanym przez specjalnego interpretera monad IO. Kompozycja monad IO jest owszem czysto funkcyjna, ale ich interpretacja już nie. Stąd, jeśli zaczynamy kopać mocno i podchodzić do tematu dogmatycznie, to wpadamy w rabbit hole
i wychodzą dziwne rzeczy. Można stworzyć np. czysto funkcyjną funkcję typu (World, String) -> World
, która wypisuje stringa na ekran poprzez przerobienie danego World
bez stringa na ekranie, na World
ze stringiem na ekranie. To byłoby skrajnie niepraktyczne, ale za to pod wszelakimi względami czysto funkcyjne. W językach ogólnego przeznaczenia gdzieś tam abstrakcje zaczynają się sypać i trzeba postawić granicę.