> > Dlaczego? Jest konsekwentny. W odróżnieniu np. od Javy, gdzie int jest
wartościowy
> > ale Integer nie jest, albo nie da się zrobić List<int>, albo gdzie wskaźniki
> > nazywane dla zmyłki referencjami są jednak wartościowe, itd.
>
> Kazdy Javowiec dobrze wie dlaczego jest ta dwoistosc (ze wzgledow
> wydajnosciowych dla typow prostych).

Nie zgadzam się. Nie ma żadnego powodu robić takiej dwoistości, żeby uzyskać
wydajność. W szczególności wydajność nie jest powodem, dla którego List<int> nie
działa. Jakoś w innych językach działa i nikt tym językom nie zarzuca braku
wydajności. To, że w Javie nie działa List<int> wynika z tego, że projektanci Javy
nie mieli jaj, żeby od początku zrobić prawdziwe generyki, zamiast tego zrobili jakąś
cienką nakładkę na referencyjno-obiektowy system pod spodem. Dlatego musi być
List<Integer> - bo akurat to da się *łatwo* zaimplementować przez tzw. wymazywanie
typów ("type erasure" dla poliglotów) tak, żeby wyszło z tego List<Object>, bo to już
umieli wcześniej. Tymczasem zarówno Ada jak i C++ potrafią zrobić kontener z
elementami typu prostego tak samo, jak kontener z elementami referencyjnymi i w obu
przypadkach jest tak samo (tzn. maksymalnie) wydajnie.

Nie gloryfikuj amatorszczyzny. Schizofrenia Javowego systemu typów nie ma żadnego
związku z wydajnością.

> Jest jednak zawsze alternatywa int:Integer

Ale właśnie ta alternatywa jest kompletnie po nic. To nie jest ficzer, to jest
właśnie defekt, bo nie ma powodu, żeby liczbę naturalną wyrażać na więcej, niż jeden
sposób. To jest ten moment, kiedy patrzysz w popękane lustro i cieszysz się, że jest
Ciebie tak wielu. Nie, masz po prostu popsute lutro.

> i w zaleznosci od potrzeb

Potrzeba jest zawsze jedna. To język zmusza programistę do myślenia na dwa sposoby o
tym samym. To jest właśnie defekt (popsute lustro).

> W C++ nie ma żadnej (a to "podobno" obiektowy jezyk:).

Nie ma żadnego problemu, żeby zrobić list<shared_ptr<int> >. Ale taka "alternatywa"
nie ma związku z obiektowością. Zwłaszcza, że lista liczb to w ogóle nie jest problem
obiektowy.

Nie mieszaj pojęć.

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