W dniu czwartek, 14 lutego 2013 23:57:25 UTC+1 użytkownik Andrzej Jarzabek napisał:

> DLL-ki to tylko trick, który ułatwia życie. Częścią definicji języka
> (jego modelu kompilacji) są object files.

Nie są. Np. C++ coś tam wspomina, że translation units mogą być translowane osobno i
potem zlinkowane, ale kompletnie niczego nie określa. Można sobie wyobrazić
implementację, która używa w tym celu bazy danych.

> Rozwiązanie, w którym ja
> dostarczam program korzystający z funkcji w postaci zestawu object
> files, a kto inny dostarcza tych funkcji w postaci object files, a
> klient sobie to wszystko linkuje statycznie linkerem przed uruchomieniem
> ma dokładnie ten sam problem,

Nie musi mieć i np. w Adzie nie ma. To, że ma w C++ wynika z badziewności typowego
zestawu narzędzi, ale nie z języka.
DLL już całkowicie jest poza językiem. Jak Ci nie działa, to naprawiaj to tam, gdzie
jest zepsute, czyli nie w języku.

> Problem jest taki, że coupling między skompilowanymi object files jest
> tight - muszą być skompilowanymi z tymi samymi definicjami typów, bo
> inaczej nie ma żadnych gwarancji na to, że będzie działało.

I bardzo dobrze. To jest zaleta statycznego systemu.

> No więc sam masz przykład na to, że w pewnych realnych sytuacjach
> spotykanych w dużych systemach taki np. C++ po prostu nie działa dobrze,
> bo musisz "wychodzić poza język" i "używać dynamicznych tricków".

Jeżeli dynamiczne techniki nie działają a statyczne działają, to jaki z tego wniosek
w kontekście tytułu tego wątku?

> >> W języku statycznie typowanym możesz mieć nawet:
> >> TreeSet s = new TreeSet();
> >> s.add(new CannotCompare());
>
> > To nie jest język statycznie typowany, nawet jeśli tak ma napisane na pudełku.
>
> Niby dlaczego? Biorąc pod uwagę całą historię języków statycznie
> typowanych,

OK, w takim razie nie dogadaliśmy się. Ty piszesz o tym, że nawet języki statyczne
dają narzędzia do strzelania sobie w stopę i to wiadomo.
Ja piszę o tym, że przynajmniej wiadomo, jaki jest zakres użycia tych niebezpiecznych
ficzerów: ja dynamiczność jest tylko tam, gdzie ja chcę ją mieć (w szczególności
nigdzie) a nie totalnie wszędzie, bez wyboru.

> No to proszę bardzo, przykład w C++:

> B& b = dynamic_cast<B&> a;

> Skompiluje się?

Tak. Jeżeli dynamiczne ficzery prowadzą do programów, które nie działają, to est to
argument przeciwko dynamicznym ficzerom.

> Jeśli uważasz, że dynamic_cast jest dynamicznym trickiem
> i dlatego działa źle, to zamień sobie na static_cast i zastanów się, czy
> na pewno będzie lepiej.

UB. Język wyraźnie mówi, że nie wolno tego static cast zrobić. Kompilator nie nadąża,
więc może język jest za mało statyczny?

Jeżeli jakiś ficzer prowadzi do programów, które nie działają, to jest to argument
przeciwko temu ficzerowi.
Nie rozumiem, jak język dynamiczny miałby poprawić poprawność w tym kontekście.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com