Hm ... Pogresio si poprilicno. Kao prvo pozvao si konsturuktor a taj konstruktor ne inicijalizuje niz. To bi se u Javi manifestovalo kao NullPointerException. Dakle, moras da pozoves drugi konstruktor, onaj kome se predaju imena.

Uzgred, enkapsulacija je majka OO programiranja. Izbegavaj da atributi klase budu public. Dakle, "uvek" atribute deklarisi kao private, a pristup njima ide kroz get - set metode. To je bar u C# lepo reseno.
Ono "uvek" je namerno u navodnicima, jer nije bas uvek, postoji mnogo mnogo polemika, ali za pocetak shvati to kao dobru programersku praksu.

Što se greške tiče, u klasi TestClass ti ponovo instanciraš odeljenje (dakle to više nije ono isto odeljenje koje si napravio u Main()) i pozivaš prazni konstruktor koji ne radi ništa (niz nije inicijalizovan). Počni od početka da radiš profi i piši:


Što se drugog pitanja tiče, da, možeš da pristupiš sačuvanim podacima. Da si u Main(), posle a.Ispisivanje() rekao , to bi radilo.

Naravno, kao što je pomenuo Mr. Beograd, nije dobra praksa izlagati tek tako nizove sa kojima klasa interno radi da budu public.

U jeziku kao C# teško mogu da smislim situaciju kad bi polja trebalo da budu public, tim pre što postoje properties.

Relja:
Ovde je DT napisao nesto sa cim se ja ne slazem, pa sam mu obrisao poruku. ;) U stvari kliknuo sam na pogresno dugme - izmena umesto odgovora. Ah taj usability.

[Ovu poruku je menjao Reljam dana 27.07.2004. u 08:50 GMT]

Sasvim tako. Kao sto rekoh, enkapsulacija je jako bitna stvar. Jedina mi je zelja bila da posavetujem, a da nekako izbegnem polemiku oko objektnog dizajna. (Mada, kad malo bolje razmislim, gde cemo da polemisemo ako ne na forumu )

Mala digresija, prvo sto mi je upalo u oko to je public deklaracija atributa, a tek posle sam video sta i kako decko instancira i poziva.

Ja lično ne volim propertije zbog mogućih sajd efekata. Reći ćete da je sve do kvalitetnog kodiranja, ali više volim kad sam jezik forsira kvalitetno kodiranje. Drugim rečima, u C# neko može u get sekciji nekog recimo int propertija da opali SQL kveri od 10 sekundi. Sa stanovišta nekog ko tu klasu koristi (a ne zna šta se u njoj dešava), dodela tipa "a.propName = 4" će trajati 10 sekundi. Ako, nasuprot tome, napravi metodu SetValueInDB(int v), neće izgledati čudno ako njeno izvršavanje traje 10 sekundi.

Ima dosta polemike na tu temu na netu.

Sasvim tako Jablane, ali ...
Meni je trebalo vremena da se naviknem (ako sam se uopste i moze reci da sam se navikao) i prihvatio sam tu praksu. Jer, uvek treba programirati u duhu jezika.
Ipak, primer ti nije bas ilustrativan. Jeste "... moze neko ..." Ali onda je to greska developera. Jer moze i property, koji ce da radi prosti (prosto prosiren) get - set, a za nesto poput toga se lepo napravi metoda smislenog imena.

Hvala vam na brzom odgovoru. Kapiram ono za properties i da atributi budu private.

A ovo drugo...
Kada Jablan kaze:



To znaci da napravljenom nizu (clanovima niza - "Pera", "Ana", "Mika", "Sanja") mogu da pristupim samo iz Main-a preko objekta "a" ili iz klase Odeljenje,a nema sanse da mu pristupim iz klase TestClass???

Pozdrav.

Prvo, izvini za brisanje originalne poruke, nije bilo namerno. A sada malo o prop's ima:

Upravo suprotno. Sva polja koja trebaju korisnicima treba da budu public. Onda kada ti zatreba da nesto ima get / set accessore, onda to polje pretvoris u property. Ovo moze da se uradi bez ikakvih posledica po ostatak programa.

Potpuno je bespotrebno pisati ovakav kod:

int privateA;
public int publicA
{
get { return privateA; }
set { privateA = value; }
}

.NET ima mogucnost da bez posledica predjes sa polja na property. Vredi to iskoristiti.

Ne, pogrešno si me shvatio ili sam bio previše nejasan. Možeš da pristupiš i iz TestClass, ali ti nisi to radio, već si u TestClass ponovo kreirao odeljenje. Možeš da uradiš nešto ovako:

Valjda sam sad jasniji.

Sa ovim se u potpunosti slažem. Nema potrebe pisati "prazne" propertije, a viđam da ljudi često to rade.

hehe, relja me preduhitrio.. baš sam isto hteo da prokomentarišem, tj naslutio sam čak i šta će reći dok sam još čitao izmenjenu nemanjinu poruku.. ;)

elem, ja sam ovu osobinu voleo još u delphiju.. a delphi je imao još i poseban scope published koji se ponašao isto kao public, osim što je dopuštao samo propertije, pa si tako mogao sam sebe da kontrolišeš.. ;)


e sad, ovo što je relja rekao nije baš 100% tačno, jer postoji razlog zbog koga sam ja ipak svako public polje pretvarao u property. na sreću pa delphi čak i to okakšava kada se property direktno mapira na polje (znači bez get/set accessora), prostijom sintaxom tipa property Active: boolean read fActive write fActive;.

a razlog je taj što se property ipak ne može koristiti baš svuda kao i polje. jedan primer su recimo i parametri koji se prenose preko reference (i out u c#). i moram da priznam da sam pomalo bio razočaran što ovu mogućnost nisu ubacili u c#, jer mi se čini da su ipak imali više manevarskog prostora..

mislim, u delphiju se parametar prenosi (uglavnom) kao običan pointer (zbog efikasnosti, kompajliranja, etc), pa je nemoguće preneti podatke o potencijalnim aksesorima neophodnim za rad propertija, ali mi se to čini mnogo lakše izvodljivo kada se sve izvršava u VMu..

relja, ovo mi baš deluje kao zanimljivo pitanje.. da li možda možeš da iščačkaš nešto više o ovoj temi/odluci od .NET tima/iz interne dokumentacije? IMHO, bilo bi vrlo zgodno kada bi property mogao da se ponaša apsolutno isto kao i obično polje. ili bih bar voleo da saznam razloge zašto to nije poželjno/izvodljivo u .NET?


--
bože, ponekad sam sebe podsećam na onaj kliše iz "ratova programskih jezika", kada na kraju rasprave samo uleti delphi zealot i kaže "pih, mi sve to imamo već 10ak godina".. :-P

Zombie, nije mi najjasnije na sta si mislio (a upravo sam se vratio sa afterpartyja posle prvog dana DirectX Meltdown-a), tako da molim te daj primer u kodu field-a koj ne moze da se napise kao property. Pretpostavljam da mislis na field koji ces da koristis kao neki ref ili out parameter? Ajde da probamo, pa ako ne upali, znam ko zna zasto. :)

Ukapirao sam. Hvala na savetima.

ma da, mislio sam na najobičnije prosleđivanje propertija kao ref/out parametra..



koliko sam upoznat, ovo ne prolazi..


a u međuvremenu se setih još jednog razloga zašto je poželjno umesto javnih polja koristiti propertije (čak i ako direktno mapiraju neko polje), a to je nasleđivanje.

elem, polja se ne nasleđuju, a ponekad je potrebno promeniti način pristupa nekim poljima u nekoj kasnijoj klasi: (naravno, primer je banalan, ali zamislite neki komplikovaniji, real-life example)



elem, mene interesuje kako bi se C# ponašao sa ovako nečim? (ne mogu ovde trenutno da proverim)..

delphi će u sličnoj konstrukciji (valjda) samo javiti upozorenje o redeklaraciji Width, ali pristup neće ići preko aksesora nego će se direktno čitati/pisati Width polje Shape klase (što nije baš lepo).


a što se prednosti samih propertija tiče, ima i primera čisto sintaxne prirode, koji ipak mogu mnogo da doprinesu čitljivosti koda, kada je mnogo elegantnije koristiti ih: (malo "razrađen" primer koji je degojs dao na nemanjinom blogu ;)



mislim, uporedite to sa one-linerom a.width += b.width++; :-P

<rant>mada, ni u delphiju ovo ne bi moglo baš toliko elegantno, jer u njemu dodela nije expression već statement.</rant>


na kraju, sve se svodi na nivo apstrakcije kome težimo, i koji properties samo povećavaju. a apstrakcija je osnovni principi i glavna vodilja u programiranju (apstrakuj sve što može nezavisno da se promeni)..

OK, priznajem da si u pravu. Mada, C++/CLI uvodi nešto što se zove "trivial properties", pa možeš da napišeš prosto



i to će da rezultuje potpuno istim kodom ispod haube.

Doduše, get/set metode (uključujući i propertyje) umeju da budu znak lošeg dizajna klase, ali to je opet priča za drugu temu.

Isto kao i Delphi. U stvari, tvojom logikom, ovako nešto bi trebalo da prođe:



ali naravno javlja grešku pri kompajliranju

Treba ti new deklaracija da bi "ukrao" identifikator u nasleđenoj klasi, a inače se potpuno isto ponaša sa i bez new, tj tretira ih kao dva različita polja.



ovo rešava stvar sa promocijom polja, i Polje je publikovano kao property u Sonny klasi, ali nažalost polimorfizam mu nije jača strana, tj kad se pojavi side-code u set accessor-u javljaju se problemi:



Polje postane 2, ali SqrPolje ostaje 0. Upravo iz ovog razloga nije dozvoljen override za promociju polja u property.
Ima još jedan caka u korist property-a, a to je registrovanje net klasa kao COM objekata, tada klijent vidi samo property-e (COM ne podržava polja). Kad se postavi pitanje "šta kao polja a šta kao property" tu je sve (kao i uvek) stvar dobrog planiranja...


Inače apropo prosleđivanja property-a kao ref parametara, to sumnjam da će ikad biti. CLI za smeštanje vrednosti u value ref parametar koristi stind (store indirect) komandu, dok se smeštanje u property obavlja sa callvirt nad set_xxxx skrivenim metodom, tj set accessorom. Pošto ti za ovo drugo treba i referenca na sam objekat , kako će metoda sa ref parametrom da razlikuje ta dva slučaja? Ne može čak ni da tretira null-reference kao upotrebu non-property-a, pošto onda neće moći da se razlikuje static property i non-property Mrka kapa, čini mi se...

Nego, ček, ček...

Relja, povlačim priznanje da si u pravu.

Ako stavimo public polja u public klase u nekom dll-u, onda će korisnici morati da rekompajliraju kod ako prebacimo polje da bude property. Zar ne?

Moraće da rekompajliraju, ali ne i da menjaju svoj kod.

Što je ok ako je sav source pod tvojom kontrolom, ali ako "prodaješ" neke kontrole ili druge public assembly-e koji će završavati u tuđim GACovima, ta promena će učiniti da stari i novi assembly budu nekompatibilni, automatski moraš da digneš major i/ili minor broj u oznaci verzije da bi GAC zadržao obe verzije.
A onda ide spika sa klijentima:
- zašto nas terate na novu verziju, šta to ima novo?
- pa znate, promenili smo polje da bude property

Sve zavisi. Niko ne kaže da će ta promena biti jedina, možeš da ponudiš i dodatno optimizovane rutine i još koješta. Nije u tome poenta.

Stvar je u tome što korišćenje public polja umesto property-ja donosi druge probleme - vezane za nasleđivanje, kako već reče zombi (a "new" nije rešenje što si i sam demonstrirao i namena mu je druga, za verzioniranje i kada ga vidimo, trebalo bi da pogledamo šta je to što nije sakriveno sa override).

Reljin primer je OK, ali samo ako ne idemo "daleko" sa njim - u tu svrhu trebalo bi prvo da vidimo kakva će biti upotreba klase. Ako se očekuje nasleđivanje (većina slučajeva), ne treba da ih (javna polja) koristimo. Ali svakako ostaje tačno ono da će prelazak biti lagan, kada zatreba.

Dakle, teško je reći ko je u pravu, jer Relja nije pogrešio - prelazak ostaje lagan, mada, ja bih se odmah odlučio za svojstva a ne javna polja - ne znam šta se dobiva ovim skraćivanjem - manje kucanja sada? Staviš plug-in koji generiše get/set za tebe, opkoliš ih sa #region i #endregion i ćao.

Kamo sreće kad bi neke firme tako radile. Infragistics prvi pati od nepoznavanja verzioniranja assembly-a, neretko se dešavalo da puste hotfix sa maintenenace verzijom DLLa (znači isti major i minor) u kome je interfejs klase promenjen, što je izazivalo pucanje postojećih modula i tražilo ponovni rebuild i redeploy celog sistema, umesto samo onog dela kome je potreban hotfix. Ni drugi nisu baš imuni na ovo.


Jedini problem su performanse, ništa više. Nikako kao poperty ne bih ostavio nešto što će biti korišćeno u ogromnom broju iteracija. Milion puta uraditi obj.Polje+=obj.Polje2; zapravo znači 3 miliona puta pozvati get ili set accessor (callvirt tj. ekvivaletno pozivanju virtuelne metode). Samo treba dobro isplanirati stvari.

Hehehe, ovo me podseća na COM i GUID-e. Tačno sam znao da će tako nešto da se desi.

[Ovu poruku je menjao Dragi Tata dana 29.07.2004. u 19:40 GMT]

to me užasno asocira na problem koji bi JIT kompajler možda mogao (trebao? ;) da provali i reši, običnim inline ubacivanjem koda umesto pozivanjem virt. metoda, ne?

mislim, naravno da na nivou ILa nema govora o ovome zbog potencijalnog nasleđivanja klase i slično, ali mi se čini da JIT ima mnogo više informacija o kodu koji kompajlira, u smislu da može da (deterministički) odredi da li se na tom mestu može naći samo instanca klase čiji kod može efikasno da se ubaci inline.

ili, ako bih bio smeo da idem i korak dalje (pa da rizikujem da lupim neku glupost, jer nisam dovoljno upoznat), možda bi tu čak bilo moguće koristiti i malo RTTI da se proveri instanca koje klase je dospela do tog dela koda, i da se izvrši odgovarajući (optimizovani) kod.


na kraju, verovatno sam nešto i lupio, ali pojenta je da toliko navaljujem pošto ne verujem u "rešenja" koja nam onemogućavaju da koristimo neki feature jezika zbog nemogućnost kompajlera da proizvede najoptimizovaniji kod (bar u ovoj inkarnaciji), jer su po pravilu sva takva rešenja "manje elegantna", "manje proširiva", ili jednostavno "manje dobra".. ;)

na kraju krajeva, takvo rešenje smo imali u vidu C/C++, ali smo se valjda već dogovorili da to ne želimo.. (sad će nemanja da me spali na lomači.. ;)

Gde sam samo zaturio šibicu? :)

C++ radi upravo ono što bi ti želeo da JIT radi a ne radi (provereno) - izoptimizuje get/set inline funkcije, pa je mašinski kod u oba slučaja isti. U C++u nema baš nikakvog opravdanja za korišćenje javnih polja (pozdrav Relji :) ).

Inače, penali u performansama kod property-ja su u praksi verovatno vidljivi samo unutar "kritičnih" petlji, i mmix se na vreme "ogradio" u tom smislu. Ono što je meni interesantnije od performansi (ne verujem da bi danas neko koristio .NET za kod od kog se očekuju visoke performanse) su posledice koje upotreba property-ja ima na čitljivost koda - nisam oduševljen da se nešto što je u suštini metod koristi istom sintaksom kao i polja.

Upravo tako - ako ćemo da se brinemo koliko gubimo na performansama zbog upotrebe svojstava a ne javnih polja, možda bi bilo najbolje koristiti nešto drugo a ne .NET.


..što samo govori u prilog onom gore.

Ok, treba da razdvojimo dve kategorije interfejsa: javne i privatne.

Javni interfejsi su ozbiljna stvar: ako nesto treba da se promeni, onda se ne 'menja' interfejs vec se izbacuje novi. Znaci ako postoji IMojInterfejs i ispostavi se da je potrebno da se nesto promeni, onda se predje na IMojInterfejs2, i to je to. Tu ne samo da korisnici treba da rekompajliraju, nego treba i da se osecaju srecno ako prodju bez promene koda. :) U krajnjoj liniji uvek se i dalje isporucuje IMojInterfejs tako da ako neko nece da se upgraduje slobodno moze da koristi stari interfejs.

Malo ozbiljnije o promeni koda od malopre - obicno ako postoji razlog da se izbaci nov interfejs, to nije samo zato da bi se field pretvorio u property, vec da bi se nesto dodalo / oduzelo / promenilo / iskoristio drugaciji model - to skoro uvek znaci da ce korisnici moraju da menjaju svoj kod, ali tako to ide. Nazalost, laksi nacin ne postoji.

Drugim recima, ako u vreme shippovanja ne postoji razlog da nesto bude property, onda moze da bude field.

Sto se tice privatnih interfejsa, tu je stvar mnogo laksa, ako nema potrebe nesto komplikovati - onda zasto to raditi. Nije cilj dizajn radi dizajna, vec dizajn radi prakticnosti.

Naravno, sve se svodi na konkretne slucajeve - negde treba koristiti jedno, negdo drugo, a negde treba sve to treba izoptimizovati jer je brzina krucijalna. Sve je stvar osecaja.

I da, ja volim public promenljive u internim C++ klasama! Bwahahaha!

Upravo ovo je bila i moja poenta. Mislim, uvaženi auditorijum ovde se po mom mišljenju preterano udubio u tehničke aspekte propertija, zanemarujući malo one socijalne. Budite svesni da ima mnogo neiskusnih (neću reći loših jer je kod programiranja uglavnom do iskustva) programera koji trpaju svašta u propertije (ono što bi inače išlo u metode), posle to i oni i drugi koriste i zaboravi se šta stoji u "crnoj kutiji" i aplikacije se vuku i onda to neko (po običaju ja) treba da dibagira i provaljuje.

Drugim rečima, što više feature-a, to više zloupotrebe istih. Koliko kapiram, propertiji su samo "skraćenice" za pisanje get i set aksesor metoda. Nekom skrate pisanje za 3 sekunde, nekom zagorčaju život.

ReljaM: dobrodosli u nov nacin moderisanja - izmenu i brisanje poruka po zelji, i tako u nedogled.

Ja se stvarno izvinjavam mmixu cija je poruka stradala kao i DTova pre neki dan. Ispao sam glup, kliknuo na pogresno dugme, nema nazad, nema are you sure, i poruka je stradala - ne treba ovo koristiti pre prve jutarnje kafe.

A steta, jer je covek stvarno imao sta pametno da kaze.

[Ovu poruku je menjao Reljam dana 30.07.2004. u 10:16 GMT]

Javni vs privatni interfejsi svakako igraju značajnu ulogu u donošenju odluke, ali situacija zavisi i od veličine i složenosti koda - čak i kod privatnih interfejsa. Na primer, ja radim sa prilično velikom bibliotekom za automatsko prevođenje koja se razvija 10-ak godina i u kojoj je strogo gledano samo jedna klasa javni interfejs, a sve ostalo je privatno. Međutim, ako su te "privatne" klase puno korišćene unutar biblioteke, vrlo je važno da se polja dobro izoluju, jer bi svaka promena unutrašnje implementacije dovela do haosa - ne među "spoljnim" korisnicima, ali svejedno bi se izgubilo puno vremena/novca da se sve dovede u red.

Za kraj malo teorije ;)

Pa da, 100%.. ali ako je to slučaj skoro da bih pitao kog đavola će ti uopšte objektni pristup? :-)

I da i ne. Ispostavlja se da klijenti (sa punim pravom) nemaju poverenja da ti njima samo das nov DLL i da je sve 'ok'. Cak i ako taj nov DLL ima samo security fixove, a kamoli nov kod. Kad god dodje do promene koda koji se isporucuje klijentima, oni to moraju dobro da istestiraju pre nego sto ce da ga stave u production environment. To je jedan i od razloga zasto .NET tipuje na verzioniranje po celoj verziji - jeste, teoretski radice ako pokupi neku drugu verziju DLLa, ali to nije nesto na sta mozes da se oslonis. Ako prodajes milionske tiraze, neces da se zezas da ti se javlja par hiljada ljudi dnevno jer im File / Print Preview ne radi ako se instalira Norton 2005 koji im je instalirao malo noviju verziju necega. Takodje, ako radis specijalizovan softver za par klijenata, uopste neces da moras da razmisljas da li ce raditi ili nece, vec se sve lepo rekompajlira. Postoji razlog zasto onolike firme guraju neki VB 3 softver koji se vrti na Win98 - nije zato sto je to sjajna platforma, vec zato sto je riskantno upgradovati stvari koje bi u teoriji radile.

Kod DirectXa je druga prica - 3D hardver se toliko menja, da to sa sobom vuce citave promene modela programiranja (gde odose render stateovi, FVF vertex deklaracije, itd), a to sa sobom nosi nove interfejse. Naravno, DirectX je i specijalan slucaj po tome sto igrama nije bitno da se rekompajliraju i da rade na sledecoj verziji DirectXa - to je vrlo veliki non-goal. Znaci ISVovi koji rade igre ce za sledecu verziju igre u 80% slucaja morati da pisu engine ispocetka (ili da uloze ogroman trud, svejedno) jer se hardver dovoljno promenio, a u drugih 20% mogu komotno da se zadrze na istom interfejsu kao i ranije, niko ih ne tera da se upgradeuju.

_{//edit - degojs: Relja, citirao si mmix-a (a ne zombija), pa sam to i promenio (tako se to radi, bez brisanja :)}

ćuti, dobro da sam video da si ovo izmenio i promenio deo koji si citirao, jer u prvoj verziji nisam uopšte shvatio kakve je ono veze imalo sa GUIDovima.. :-P

(uplašio sam se za sebe i svoj zdrav razum ;)



hm.. tako nešto bi mogao i JIT da uradi, ali samo ponekad.. kaži mi kako C++ kompajlira (inline) ovakav kod? a tek neki još komplikovaniji, ili manje očigledni?



zato sam pominjao (determinističko) određivanje klase i RTTI. a meni se čini da bi JIT možda imao i prednost kod ovakvih stvari, jer nesumnjivo ima više podataka o kodu koji kompajlira nego C++ kompajler. (btw, jel mi svo vreme pričamo o MC++, ili C++/CLI, ili standardnom C++, ili nečemu trećem? pogubih se više.. ;)



to se može reći i za "obične" metode, pa i za same klase. da bi nešto uspeštno koristio kao crnu kutiju, moraš ipak imati neko osnovno znanje o konstrukciji iste (čitaj: kutija nikada nije baš skroz crna). ako ne pročitaš dokumentaciju u kojoj lepo piše da klasa nije thread-safe, i/ili da njeno instanciranje izvršava neki SQL upit od 10+ sekundi, i ako objekte te klase kreiraš u okviru velike petlje, niko ti ne može pomoći..



meni se baš čini suprotnim.. svojstva baš olakšavaju pisanje koda za sve koje mrzi ili ni ne znaju zašto (uglavnom) nije uputno držati polja javno dostupna. ovo se naročito odnosi na te "neukusne" koje ti pominješ. takvima bi ja i bukvalno zabranio (dok ne nauče) da im klase imaju javna polja, iako znam da se ni jednog pravila nije pametno pridržavati baš u svakoj situaciji. ;)


// btw, glasam da se nemanji i relji ukine SM status.. bar dok ne nauče da koriste point&click interfejs.. ubijaju nam diskusije :-P

Samo polako momci, znao sam da sam negde pročitao nešto, samo mi je trebalo slobodnog vremena da prolistam i nađem gde i šta ono tačno :)

Bez uvrede prema Jesse, ali baš ovaj citat je kontradiktoran samom sebi (zapravo tako ispada jer je nedorečen). Zadnji paragraf lepo objašnjava kako funkcioniše AssemblyResolver, tj. da učitava najveći build/revision u okviru zadatog major/minor-a. (I GAC installer funkcioniše isto, zadržava samo najveći build/revision u okviru istog major/minor-a). Ali u prethodnom paragrafu stoji da dva assemblya sa istim major/minor-om, a različitim build verzijama ne moraju biti kompatibilna... Ako je cilj cele ujdurme sa strong named assembly-ma bio da se razreši COM pakao i da se spreči pucanje postojećih buildova, mora da postoji MINIMUM backward kompatibilnost. U suprotnom smeru ne mora da važi, znači meta-data se može proširiti novim tipovima, kao što je to uradio MS sa .NET Frameworkom 1.1 (koji je u stvari build release 1.0.5000). Ali koliko vidim iz prakse ni to nije baš pametno, jerbo aplikacije pisane za build 1.0.5000 koje koriste dodane tipove neće da rade na 1.0.3705 ili koji već beše.

Mislili ste tako lako da se rešite moje poruke imam ja to u triplikatu, evo kopije:


Nažalost, ova priča neće nikad zaživeti, baš zato što u accessor možeš da staviš bilo kakav kod, uključujući i unsafe kod. accsessor može biti i iz drugog assembly-a koji referencira neki treći koji nije pristan u pozivaru, a kad u priču ubaciš i remoting (gađanje "preko" application boundary-a), nastaje pakao. Verovatno bi neka anaiza mogla da se uradi ali bi tek onda dobio žešći startup lag, dok se sve to izanalizira i JITuje.



Zato .net podržava verzioniranje assembly-a po kom možeš da zadržiš dva assembly-a sa istim imenom a različitim major/minor verzijama (recimo 2.0.15.122 i 2.1.0.0). Tako da uopšte i ne moraš da ubacuješ IMojInterfejs2, možeš slobodno zadržati isti naziv interfejsa, čime još drastičnije smanjuješ potrebu za menjanjem koda kod klijenta. Stare aplikacije će i dalje biti bindovane za 2.0.x.x verziju i radiće bez problema a i dalje možeš da radiš hotfix release-ove za stariju verziju, recimo 2.0.16.1, koji neće uticati na 2.1 verziju. Uvođenje INestoNesto2, 3, 4, 5... interfejsa vodi u COM pakao, ko radi directx aplikacije zna o čemu pričam a ima i mnogo gorih primera sa enterprise paketima sa po 30-tak "upgrade" interfejsa nad jednim objektom.



Morate imati u vidu da ko god je dizajnirao .NET radio je to gradeći nad COM filozofijom, tako da je realno .NET ustvari new&improved COM. Meta-data je upgrade TLB-a, GUIDi su zamenjeni sa "fully qualified type name" (mada mislim da runtime i dalje koristi GUIDe za čuvanje tipova, ali ovo bih morao da proverim) i ubačeno je dosta novih tehnologija. Tako da su u .NET zapravo vraćena public polja kao nešto što je bilo isključeno iz COMa. Tako da ni sam nisam baš rad da za sve koristim property, naročito ako sam 100% siguran da se na get/set operacije neće lepiti side-code. Ni sam .NET Framework nije u potpunosti publikovan preko property-a, izuzev Primary Interop assembly-a.

Znam i baš zato sam i napisao ceo i taj poslednji pasus. Meni je čudno pošto MSDN jasno govori drugačije.. Ne znam baš da li bi se njemu slučajno omaklo da napiše "može ali i ne mora".. I pazi, nije Jesse jedini koji ima takav stav (npr. vidi ovde.)

Zapravo, ako ispoštuješ .net verzioniranje do kraja, znači ne samo promišljene releasove sa adekvatno uvećanim major/minor/build ili revision, nego i sa strong name, ne može da se desi da Norton2005 instalira npr "FileShare.Common .ver 1:0:1670:35038" preko tvog "FileShare.Common .ver 1:0:1000:1" pošto vam PublicKeyToken-i neće biti isti. Tako da jedinu brljotinu sa verzioniranjem i pucanjem buildova možeš da napraviš sam, ako izmeniš postojeći metadata a ne uvećaš minor.
Ja to čak i rigoroznije gledam i uvek kažem ljudima, za sve .net tipove unutar jednog assembly-a tretirajte kombinaciju (Name, major, minor i PKToken) kao COM interface GUID. Šta je jedan od osnovnih postulata COM interface-a: Interfaces are IMMUTABLE, if you change interface layout, you must assign a new GUID. U prevodu, jednom kad pustiš interface u "divljinu", više ga ne smeš menjati, možeš samo napraviti novi. Analogno u .NETu ako promeniš neki od tipova u assembly-u moraš da promeniš bar jednu stavku od onih 4, najjednostavnije je naravno povećati minor verzije... Potreban je mali trud da se ovo ispoštuje, čak i u situacijama kad je 100% koda pod vašom kontrolom, možda jednog dana neće biti i možda sebi i nekome uštedite vreme i živce.


Dobro, ovo je malo nesrećno izabran primer, priznajem. Pomenuo sam to pošto pretpostavljam da se više ljudi srelo sa DirectXom nego sa core-banking enterprise komponenetama Ali opet, zamisli da je verzioniranje rađeno po .net filozofiji. I dan danas koristio samo IDirect3D interfejs samo iz "Microsoft.Direct3D .ver 9:0:3:x" assembly-a

@zombie: Ako te interesuje inlajniranje kod C++a, obavezno pročitaj ovaj člančić Herb Suttera:
http://www.gotw.ca/gotw/033.htm

Zakljucak je da maltene ne treba uopste pisati inline funkcije nego posle uraditi profiling i profiler ce nam reci koju funkciju da stavimo inline. Obrnuto ne radi lepo, tj. profajleri nisu dobri u odredjivanju koja inline funkcija ne bi trebalo da bude inline.

to sam otprilike i sam shvatio, ali mi nije baš jasno kakve to veze ima sa onim što sam ja pitao?

tj, da uprostim, kako se radi inline-ovanje kada su u pitanju virtuelne metode (i zar nije svaki aksesor svojstva u stvari virtuelna metoda, čak i u C++)?

Ovako "sistemaški", svaki aksesor mora biti virtuelna metoda inače nije polimorfan. C++ nisam mnogo pipao zadnjih 3 godine, ali i meni se kanda čini da ovo inlajniranje ima neke frke, naročito pri nasleđivanju. Ako ja castujem objekat u nekog njegovog pretka i pozovem inlajnirani aksesor, kompajler ne može da zna koji aksesor treba da pozove, bazni ili nasleđeni, samim tim ne može da zna koji treba da inlajnira, zar ne?

Da, tako je. Virtuelne metode ne mogu da se inlineuju.

Kao sto sam rekao malopre, sve je stvar trade-offa. Zato i volim da koristim promenjive u klasama tamo gde mogu i gde ima smisla. Ako je klasa potpuno interna, i ako znas da u skoroj buducnosti nece biti potrebe za polimorfnim aksesorima, onda nemoj ni da ih stavljas da budu virtuelni - problem resen. ;)

Naravno da virtuelne funkcije ne mogu da se inlajniraju, ali aksesori najčešće nisu virtuelni.

Danas naleteh slučajno na MSovo tumačenje "nepisanih pravila" verzioniranja, možda nekog interesuje:

The version components are used by convention as follows:

Major: Assemblies with the same name but different major versions are not interchangeable. This would be appropriate, for example, for a major rewrite of a product where backward compatibility cannot be assumed.
Minor: If the name and major number on two assemblies are the same, but the minor number is different, this indicates significant enhancement with the intention of backward compatibility. This would be appropriate, for example, on a point release of a product or a fully backward compatible new version of a product.
Build: A difference in build number represents a recompilation of the same source. This would be appropriate because of processor, platform, or compiler changes.
Revision: Assemblies with the same name, major, and minor version numbers but different revisions are intended to be fully interchangeable. This would be appropriate to fix a security hole in a previously released assembly.