Ciężko mi załapać wyczucie, kiedy tworzyć nowy obiekt a kiedy modyfikować istniejący. Chodzi mi o kolekcje: mam np. zbiór wierzchołków grafu, które będę odczytywał z pliku, da się je dodawać i usuwać. Raczej mutable, prawda?
I dalej. Mam zbiór zaznaczanych (nie zaznaczonych, bo klawisz myszy nie został zwolniony) w danym momencie punktów. Korci żeby użyć zbioru immutable, no bo w końcu gdzieś trzeba.
Trzecia sprawa. Przechowywanie zaznaczonych punktów. Mam w klasie wierzchołka pole selected. Zastanawiam się czy korzystać zamiast/dodatkowo ze zbioru zaznaczonych wierzchołków. Mianowicie: gdy chcę dostać zaznaczone wierzchołki, to mogę użyć filter(v=>v.selected). Jeśli np oprócz tego stworze zbiór, to jeśli on nie będzie zmienialny, to ciągle będę przypisywać do obiektu selVerts nową kolekcję.
Cały post w jednym zdaniu: gdzie używać tych niezmiennych kolekcji?!
Jeśli ktoś ma jeszcze czas na małą dywagację:
scala jest bardzo obiekto-żerna. Funkcja dająca się wysłać do innej funkcji to nic innego jak obiekt z metodą typu apply. Dodatkowo te niezmienne kolekcje. Logiczne z matematycznego punktu widzenia, bo Set(1,2,3) po dodaniu elementu 4 jest już innym zbiorem. Ale czy to jest na komputery, z których korzystamy, czy na szybsze komputery przyszłości? Bo np funkcyjność można fajnie wykorzystać, gdyby jednocześnie wykonywać więcej obliczeń: aby uzyskać kolekcję elementów o jeden większych, dla każdego elementu można by odpalić coś w rodzaju procesu, zamiast imperatywnie przechodzić po liście i robić to po kolei. Ale mam wrażenie że w tej chwili funkcyjność to dodatkowa warstwa abstrakcji która tylko ułatwia życie programiście a utrudnia komputerowi.