W dniu 2013-02-08 18:14, Andrzej Jarzabek pisze:
> On Feb 8, 4:45 pm, darekm <d...@e...com> wrote:
>> W dniu 2013-02-07 23:51, Andrzej Jarzabek pisze:
>>
>>> A w językach z dynamicznym systemem typów nie trzeba. I na tym polega
>>> różnica - w C++ tego po prostu nie zrobisz i tyle, żaden QVariant czy
>>> hashmap ci nie pomoże.
>>
>> To że zawsze możesz użyć wszystko ma swoją drugą stronę: niczego nie
>> możesz zabronić. Przy statycznym typowaniu każda funkcja ma
>> zdefiniowane dla jakich typów i w jakim kontekście jest poprawna i w
>> innych jej nie użyjesz. A wraz ze wzrostem programu liczba kontekstów
>> niepoprawnych rośnie szybciej niż tych poprawnych.
>
> Można ograniczyć ten efekt odpowiednio projektując kod.

Przy wsparciu języka to ograniczenie jest skuteczniejsze.

>
>>> Bo zajmuje czas, bo wprowadza szum do kodu, bo utrudnia refaktoryzację.
>>> Może nie zawsze, ale przynajmniej niekiedy.
>>
>> Co zajmuje czas: wklepanie kodu? Przecież to jest czas pomijalny.
>
> Wymyślenie zestawu typów i relacji między nimi, odpowiadające
> problemowi. Przerabianie tego zestawu w miarę jak problem się zmienia.
>

Co jest prostsze: "odpowiednio" projektować kod, czy tylko wprowadzać
więcej typów wraz z ewentualnie duplikowaniem kodu, szczególnie że to
ostatnie jest w mniejszym lub większym zakresie mechaniczne.
Poza tym struktury danych i relacje między nimi masz dane w
specyfikacji. Typy to mechanizm separacji, aby błędnie nie mieszać
niewłaściwych struktur i narzędzi.


>> Refaktoryzacja: kompilator powie Ci gdzie NIE możesz użyć nowej
>> funkcji/struktury
>
> W pewnych sytuacjach tak, ale czasem ci powie, że błąd, bo typ X nie
> istnieje i faktycznie, po refaktoryzacji nie istnieje.

czyli dobrze, nieprawdaż?

>
>>> Wprowadzasz duplikację. No i pojawiają się dalsze problemy, co na
>>> przykład, jeśli chcesz skopiować structa i owej kopii dołożyć kilka
>>> nowych pól?
>>
>> Tylko wtedy gdy to ma sens, mogę zawsze przekazywać nie obiekty a pole.
>
> Przykład był przecież uproszczony, jeśli funkcja korzysta z siedmiu
> pól, to przekażesz jej siedem argumentów?
>

zacytuję:
"Można ograniczyć ten efekt odpowiednio projektując kod."


>> Po drugie to kompilator zabroni mi wywołać
>> foo(foo(c))
>
> Nawet jeśli właśnie foo(foo(c)) jest dokładnie tym, co chcesz zrobić.

Jeśli tak jest to będzie istniała odpowiednia definicja.
Jeśli nic nie zrobię to znaczy że nie chcę takiej konstrukcji.
Mam wybór.

>
>>> Piszesz konwersję kopiującą wszystkie składowe do hashmapy?
>>> I tak dla każdego typu? I nie widzisz w tym nic niewygodnego?
>>
>> W życiu też możesz używać wygodnego samochodu rodzinnego do którego
>> zapakujesz na dowolnym parkingu kilka osób, psa i śniadanie i dojedziesz
>> nad (prawie) dowolne jezioro. Z drugiej strony masz tiry, które
>> zapakujesz wyłącznie na rampie wyłącznie paletami wyłącznie mechanicznie
>> i można jeździć wyłącznie uprawnionymi drogami. Dlaczego tak skoro tak
>> niewygodnie i restrykcyjnie?
>
> Nie bardzo rozumiem, jak to się ma do tematu dyskusji. Chcesz
> powiedzieć, że samochody rodzinne są niepotrzebne, skoro można rodzinę
> zapakować w dwa tiry i wybrac sobie takie jezioro, do którego prawie
> dojeżdża uprawniona droga?

Zupełnie odwrotnie. Pytanie brzmi: dlaczego tiry są takie popularne
skoro mają tyle ograniczeń. W analogii do języków z typowaniem
statycznym, w których tyle się trzeba "napracować" aby cokolwiek działało.




--
Darek