On Feb 15, 9:37 am, Maciej Sobczak <s...@g...com> wrote:
> 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.

Nadal będziesz miał ten sam problem - jeśli twoja baza danych
przechowuje skompilowane jednostki (instantiation units w terminologii
standardu) pochodzące z różnych translacji z różnymi źródłowymi
definicjami typów danych, to nie ma żadnej gwarancji zadziałania.

Poza tym w rzeczywistości decydując o wyborze języka do tworzenia
oprogramowania sensownie kierować się implementacjami istniejącymi, a
nie tymi, które można sobie wyobrazić. Chyba że działanie programu,
który tworzysz, też masz zamiar sobie tylko wyobrażać.

> > 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.

Badziewnośc realnie dostępnych narzędzi to bardzo dobry powód, żeby w
praktyce wybrać inny język, który ma mniej badziewne narzędzia. Na
Adzie się nie znam, ale czy nie jest przypadkiem tak, że do wielu
aplikacji biznesowych byłaby słabym wyborem ze względu na brak
bibliotek i narzędzi właśnie?

> 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.

Ale jeśli przez to, że wybiorę inny język może nie być zepsute, to po
co w ogóle mam naprawiać?

> > 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.

Że się program wywali? Faktycznie, rewelacyjna zaleta.

> > 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?

Skoro programy komputerowe często nie działają, to może zamiast
komputerów lepiej używać znacznie bardziej niezawodnych pięściaków?

> > 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
[...]

Akurat rozmawiamy o tym, czy Java jest językiem statycznie czy
dynamicznie typowanym. Umówmy sie może w takim razie, że konstrukcja
pozwalająca na niebezpieczne rzutowania nie dyskwalifikuje języka z
bycia statycznie typowanym.

> > 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.

Każdy język, który jest Turing-complete ma dynamiczne ficzery, które
nie działają.

> > 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?

Jak napisałem, chodziło o sytuację, kiedy B dziedziczy po A. To jest
trywialny przypadek, więc może jakiś model checker by to wyłapał, ale
w ogólnym przypadku kompilator nie ma podstawy do stwierdzenia, czy za
referencją na A kryje się obiekt typu B, więc możnaby temu zapobiec
jedynie zabraniając downcastów w ogóle.

Zarówno Java, jak i C++, jak i wiele innych języków powszechnie
uważanych za statycznie typowane i obiektowe (czy powiedzmy
wspierające obiektowość) mają taką instytucję jak niebezpieczny
downcast.