🚀 go-pugleaf

Sektor van Skijlen napisał:

> Oczywiście, bo jest to znacznie mniej potrzebne, niż się ludziom wydaje.
> Co więcej, jest to też często zabójcze! Nałożenie dowolnego ograniczenia na
> typ-parametr powoduje od razu bardzo możliwe ograniczenia użycia takiego
> wzorca. Przykładowo, pamiętam jak jakaś klasa używała własnego type-traita do
> sprawdzenia, czy dany typ jest integer. A ja sobie zrobię np. własny typ
> integer i co? Wiem, że powinienem się w takim przypadku "dopisać do listy" i
> to rozwiązuje problem, ale z drugiej strony to może spowodować, że mój typ
> będzier traktowany jak całkowity nawet jeśli spełnia "nie wszystkie" warunki.
> 
> Jeśli już, to powinno się definiować w miarę możliwości osobne definicje dla
> różnych kwalifikacji typów.
> 
> W istocie w Javie to ograniczanie typów (tak samo zresztą jak w C#) bierze się
> wcale nie stąd, że "ludzie potrzebują ograniczania typów", tylko stąd, że tego
> wymaga runtime języka (inaczej: język nie będzie działał bez tych ograniczeń).
> W przypadku Javy jest to bardzo proste przełożenie: jeśli używany typ nie ma
> ograniczeń, to będzie implementowany przez Object; jeśli ma ograniczenie na
> bycie wyprowadzonym z określonej klasy/interfejsu - wtedy będzie
> implementowany przez referencję do tej właśnie klasy/interfejsu. Generyki
> zapewniają ci tylko tyle, że zrobią za ciebie rzutowanie.

Sektor ! To jest naprawdę wspaniałe jak mnie uczysz jak działają 
generyki w javie :-). (fakt, że przynajmniej technicznie trochę prawdy 
napisałeś)

Ale "filozoficznie" - absolutnie sie nie zgadzam. Jeśli robię jakiś 
framework z użyciem generics i narzucam, ze jakiś tam typ X można 
konkretyzować tylko klasami które np. dziedziczą z jakiejś mojej klasy 
Y, implementują jakiś interfejs.. daje mi to konkretną kontrolę i 
możliwość w miarę bezpiecznej ewolucji frameworku. Mam pewność, ze jeśli 
ktoś czegoś tam nie odziedziczy to mu się kod nie skompiluje ( kontrola 
na zasadzie:  akurat przypadkiem klasa Z ma metodę setValue() którą 
wywołuje to jak dla mnie nie jest szczęśliwe rozwiązanie)

W przypadku C++ kilka razy się potknąłem o ten problem, fakt, głownie z 
powodu przeciążania operatorów. Zaskakująco dużo istotnych typów potrafi 
  mieć przypadkiem pokryty operator + , -> czy inne takie. Niekoniecznie 
w sposób zgodny z tym jaki twórca  generycznego kodu w którym się tego 
użyje przewidywał).


>>Absolutnie źle mnie zrozumiałeś. W javie (genericsy) nie ma 
>>metaprogramowania ani trochę.
> 
> 
> Aha, jeśli tak to się zgodzę. Nie sprecyzowałeś po prostu.
> 
> 
>>I to jest zaleta. Przynajmniej patrząc na to co pamiętam z C++.
> 
> 
> No nie wiem. Jak słyszę takie rzeczy, że w Javie czegoś brakuje, co ma C++ i
> że to jest zaleta, to mnie dosłownie pusty śmiech ogarnia. Jeszcze większy,
> jak się po jakimś czasie okazuje, że to zostało częściowo potem dodane, tak
> jak było z generykami.
Widzisz bo to właśnie był sens Javy (i obecna moja tendencja do unikania 
  C++). Wyrypanie tych pięknych ficzerów:
	- bez których da się spokojnie żyć,						- i  z których umiejętnie 
korzystać potrafi 1% programistów,
	- i z których korzysta 50% reszty programistów absolutnie wypaczając sens

Dokładniej:
Makra, meta programowanie, operator overloading.
( strzelam, że obecnie mnóstwo ludzi korzysta z meta programowania do 
rozwijania prostych pętli ... co jak się nieumiejętnie robi (nie 
sprawdza) zabija wydajność zamiast poprawiać)

Powiem więcej - mimo, że w  mniejszych projektach nie mam oporów z 
korzystaniem z java generics... to przy większych projektach zespołowych 
w javie... prawdopodobnie optowałbym za nie korzystaniem z genericsów (w 
sensie tworzenia własnych typów). Czytelność i prostota kodu to jest 
element, którego nie można pominąć, a nie wiem czy chciałbym oglądać 
"generyczny" kod stworzony przez człowieka, który właśnie w swoim kraju 
przeszedł kurs "learn java in 21 hours". ( w zasadzie to w ogóle nie 
chciałbym pracować z żadnym kodem tworzonym przez takiego gościa ... 
niestety jakoś ciągle mnie i wszystkich znajomych ten problem spotyka i 
dotychczasową zaletą javy było to, że przynajmniej dawało się taki kod 
fragmentami zrozumieć i na szybkiego załatać).

Operator overloading - już raz płakałem, że tego nie mam w Javie - ale 
zaraz zrozumiałem, że miałby to wtedy także konkretny, (absolutnie 
niegłupi, tylko bardzo *kreatywny* ) pan X.

>>Poza tym, boost::mpl stracił w moich oczach dawno temu - jak niechcący 
>>zaglądnąłem do źródeł i zobaczyłem ile konstrukcji jest "sficzerowanych" 
>>chamskimi makrami. Prawda, że na oko 95% tych makr (a może troche więcej 
>>-ale na pewno nie wszystkie) to poprawki na problemy z kompilatorami 
>>(wyjątkowo często na msvc).
> 
> 
> Nie masz się czym przejmować; boostowcy przesadzają z komplikowaniem kodu. To
> jeszcze niczego nie oznacza.

Jeśli to jest ta piękna biblioteka, która ma uratować C++ 
(standaryzacja) .. to wiele znaczy.

>>To, że z C++ da sie zasymulować prawie dowolny język korzystając z makr 
>>i derektyw typu #pragma to fakt. Ale tak się składa, że w praktyce to 
>>może nie być zaleta :-).
> 
> 
> Ale tu nie chodzi o makra; te są używane wyłącznie instrumentalnie. Da się to
> wszystko napisać zupełnie bez makr, a nawet prościej. W metaprogramowaniu
> chodzi głównie o wykonywanie operacji na wartościach i typach podczas
> kompilacji. To nie wymaga jakichś specjalnych sztuczek, ani nie jest wcale tak
> często stosowane.
> 
> Ale mimo niewielu zastosowań jego istnienie jest nieocenione! Tym bardziej
> zatem nie rozumiem, dlaczego jego brak w języku miałby być zaletą, skoro w
> niczym nie przeszkadza.

Zależy jak się na to patrzy. W Javie jest coś takiego jak 
instrumentacja, refleksja, generowanie kodu w runtime... załatwia się 
tym podobną klasę problemów co meta programowaniem w C++ (czyli dość 
specyficzne, mocno technologiczne problemy).
Niestety, w praktyce załatwia się też całą masę problemów, które można 
zrobić zwyczajnie (korzystając z podstawowych własności każdego języka 
"obiektowego").
Taka, kurde.... moda. A potem kod się kompiluje pięknie tylko trzeba 
debugować, żeby odkryć czegoż to jeszcze nie dodaliśmy do naszej klasy, 
co akurat niejawnie używane jest w bibliotece XY.

> 
> I chyba destruktorów, których nie jesteś w stanie zasymulować w C w żaden
> sposób. A jest to bardzo istotny element C++.

z tego co pamiętam destruktory miałem - ale nie ja pisałem te makra więc 
  100% pewności nie mam jak to było zrobione (musiałbym sie bardzo 
umotywować, żeby to teraz na starej amidze odnaleźć :-) )

> 
> Eeee tam. No dobrze - dodają statyczną weryfikację poprawności typu. Ale to
> wszystko.
> 
> Istotnym elementem wzorców w C++ jest ich "efficiency". Dlatego jest to

Ale w jakim sensie  *efficiency* ?
To oczywiście była wielka kłótnia przy wprowadzaniu java generics jak to 
ma być kompilowane. W praktyce gdyby przyjęto model z C++ - 
kompilowaniem nowego kodu dla każdej konkretyzacji... to niewiele by się 
  zmieniło (poza rozmiarami programów wynikowych).
(OK. byłyby duże zmiany w refleksji - ale to jest ( w kontekście 
porównania z C++) wewnątrzjavowy problem).

-- 
http://www.99-bottles-of-beer.net/language-java-866.html