Re: Da li ce Longhorn biti 100% .NET?Citat:
ambimoustrous: Pitanje #1.
Da li možete reći nešto više o ovome? Da li postoje opšte prihvaćeni kriterijumi za ocenjivanje dizajna biblioteke klasa? Zašto bi Microsoft sa svim njihovim resursima (ljudskim i finansijskim) omanuo po ovom pitanju? Voleo bih da dobijem neku vrstu odgovora, sa obzirom da ste me zaintrigirali ovom tvrdnjom.
Pitanje #2.
Da li se .NET BCL klase nadovezuju na WinAPI? Da li njihovu funkcionalnost obezbeđuje WinAPI, ili je u pitanju potpuno nezavisan podsistem?
Naime, ako .NET klase koriste WinAPI, onda mi se čini da nema razloga prerano proglašavati kraj API-ja.
Da li možete reći nešto više o ovome? Da li postoje opšte prihvaćeni kriterijumi za ocenjivanje dizajna biblioteke klasa? Zašto bi Microsoft sa svim njihovim resursima (ljudskim i finansijskim) omanuo po ovom pitanju? Voleo bih da dobijem neku vrstu odgovora, sa obzirom da ste me zaintrigirali ovom tvrdnjom.
Pitanje #2.
Da li se .NET BCL klase nadovezuju na WinAPI? Da li njihovu funkcionalnost obezbeđuje WinAPI, ili je u pitanju potpuno nezavisan podsistem?
Naime, ako .NET klase koriste WinAPI, onda mi se čini da nema razloga prerano proglašavati kraj API-ja.
Ovde nije običaj da persiramo jedan drugome pa ću, ako nemaš ništa protiv, da se držim tog običaja.
#1 Najpre da odmah raščistim da ne postoje opšte prihvaćeni kriterijumi za ocenjivanje dizajna klasa i to je i dalje više stvar ličnog ukusa nego preciznih metrika. Tako da ovde iznosim čisto svoje mišljenje sa kojim se mnogi ne slažu, ali se mnogi i slažu.
Mislim da je kod dizajna .NET BCL-a učinjen ozbiljan promašaj odmah u startu: izabrana je klasična OO arhitektura nalik na SmallTalk hijerarhiju koja je bila "state of the art" 80-ih, ali danas je već uveliko zastarela. Istu grešku su napravili i dizajneri Java API-ja i sad su Javine klase pravo zamešateljstvo puno dupliciranih funkcionalnosti i "deprecated" metoda, klasa i celih paketa koji i dalje moraju da budu prisutni zbog kompatibilnosti. Najsmešnije je što i .NET klase počinju da pate od bukvalno istih problema: uskoro ćemo imati dve odvojene GUI biblioteke (Win Forms i Avalon) baš kao što i Java ima (AWT i Swing), postojeće kolekcije postaju zastarele sa dolaskom novih u VS 2005 (a što je najgore ni te nove ne valjaju, pa je Microsoft inicirao neke spoljne saradnike da naprave dobre kolekcije - pogledaj Power Collections). Klase su ogromne, teško pregledne, sa prevelikim brojem metoda, i previše se koristi nasleđivanje kao sredstvo za "code reuse". Da i ne pominjem da je jako teško snaći se u toj džungli od klasa, što indirektno priznaju i u Microsoftu.
Jednostavno, "klasičan" OO ne skalira dovoljno dobro da pokrije ovako veliku biblioteku i to nije ništa novo, pa ljudi traže bolja rešenja - npr AOP. Microsoft je rešio da ne rizikuje previše sa tim (relativno) novim tehnikama i da koristi principe koji su poznati većem broju programera, ali samo je pitanje vremena kad ćemo da dobijemo Java-like kupusaru.
#2. Iskreno, ne znam. Da li .NET klase interno zovu Win32 API ili direktno subsystem nezavisne API-je nije mi poznato u ovom trenutku.
