Srodne teme
Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase

[es] :: .NET :: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase

Strane: 1 2 3

[ Pregleda: 7316 | Odgovora: 44 ] > FB > Twit

Postavi temu Odgovori

Autor
Pretraga teme: Traži
Markiranje Štampanje RSS

degojs

Član broj: 4716
Poruke: 5096



+51 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase29.07.2004. u 07:13 - pre 241 meseci
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.
Commercial-Free !!!
 
Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042



+4631 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase29.07.2004. u 21:52 - pre 241 meseci
Citat:
degojs: 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.

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.

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

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.
Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan, sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv… - Z.Đinđić
 
Odgovor na temu

Dragi Tata
Malo ispod Kanade

Član broj: 1958
Poruke: 3906
*.bos.east.verizon.net



+6 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase29.07.2004. u 23:09 - pre 241 meseci
Citat:
mmix: 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


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]
IOCC
 
Odgovor na temu

-zombie-
Tomica Jovanovic
freelance programmer
ni.ac.yu

Član broj: 4128
Poruke: 3448
*.dial.InfoSky.Net

Sajt: localhost


+5 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase30.07.2004. u 02:16 - pre 241 meseci
Citat:
mmix:
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.


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.. ;)
blogče :: unescaped beta
　 » go-paste extenzija
　 » reč dana: backup
　 » bočne koalicije
 
Odgovor na temu

Dragi Tata
Malo ispod Kanade

Član broj: 1958
Poruke: 3906
*.bos.east.verizon.net



+6 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase30.07.2004. u 02:37 - pre 241 meseci
Citat:
-zombie-: (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.
IOCC
 
Odgovor na temu

degojs

Član broj: 4716
Poruke: 5096



+51 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase30.07.2004. u 03:36 - pre 241 meseci
Citat:
Dragi Tata:
ne verujem da bi danas neko koristio .NET za kod od kog se očekuju visoke performanse

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.

Citat:
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 :) ).

..što samo govori u prilog onom gore.
Commercial-Free !!!
 
Odgovor na temu

Reljam
Relja Markovic
San Francisco

Član broj: 531
Poruke: 1793
*.client.comcast.net



+18 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase30.07.2004. u 07:07 - pre 241 meseci
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!
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541



+711 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase30.07.2004. u 07:39 - pre 241 meseci
Citat:
Dragi Tata: 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 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.
 
Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042



+4631 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase30.07.2004. u 13:37 - pre 241 meseci
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]
Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan, sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv… - Z.Đinđić
 
Odgovor na temu

Dragi Tata
Malo ispod Kanade

Član broj: 1958
Poruke: 3906
66.228.70.*



+6 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase30.07.2004. u 14:11 - pre 241 meseci
Citat:
Reljam: Ok, treba da razdvojimo dve kategorije interfejsa: javne i privatne.

...

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.


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 ;)


Citat:
Booch: Object-Oriented Analysis and Design: No part of a complex system should depend on internal details of any other part ... encapsulation allows changes to be reliably made with limited effort.


Citat:
GoF: Design Patterns: Requests are the only way to get an object to execute an operation. Operations are the only way to change the object's internal data. Because of these restrictions, the object's internal state is said to be encapsulated
IOCC
 
Odgovor na temu

degojs

Član broj: 4716
Poruke: 5096



+51 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase30.07.2004. u 16:18 - pre 241 meseci
Citat:
Miljan:
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.


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

Reljam
Relja Markovic
San Francisco

Član broj: 531
Poruke: 1793
*.client.comcast.net



+18 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase30.07.2004. u 17:14 - pre 241 meseci
Citat:
mmix:
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 ...

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 :)
 
Odgovor na temu

-zombie-
Tomica Jovanovic
freelance programmer
ni.ac.yu

Član broj: 4128
Poruke: 3448
*.dial.InfoSky.Net

Sajt: localhost


+5 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase31.07.2004. u 09:14 - pre 241 meseci
Citat:
Dragi Tata:
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]


ć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 ;)

Citat:
Dragi Tata:
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.


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?

Code:
class Tatko {
    public int Svojstvo { // get, set }
}

class Sinko: Tatko {
    public int Svojstvo { // neki drugi get i set }
}

Tatko o;
if ((new Random()).Next(3)>0) {
    o = new Tatko();
} else {
    o = new Sinko();
}
o.Svojstvo++;


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

Citat:
jablan:
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.


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

Citat:
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. ;)


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
blogče :: unescaped beta
　 » go-paste extenzija
　 » reč dana: backup
　 » bočne koalicije
 
Odgovor na temu

degojs

Član broj: 4716
Poruke: 5096



+51 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase31.07.2004. u 10:34 - pre 241 meseci
Citat:
Dragi Tata:
Citat:
mmix:
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

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


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 :)

Citat:
Jesse Liberty - "Programming C#":

A version number for an assembly might look like this: 1:0:2204:21 (four numbers, separated by colons). The first two numbers (1:0) are the major and minor versions. The third number (2204) is the build, and the fourth (21) is the revision.

When two assemblies have different major or minor numbers, they are considered to be incompatible. When they have different build numbers, they might or might not be compatible, and when they have different revision numbers, they are considered definitely compatible with each other.

Revision numbers are intended for bug fixes. If you fix a bug and are prepared to certify that your DLL is fully backward-compatible with the existing version, you should increment the revision. When an application loads an assembly, it specifies the major and minor version that it wants, and the AssemblyResolver finds the highest build and revision numbers.

Commercial-Free !!!
 
Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042



+4631 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase31.07.2004. u 11:27 - pre 241 meseci
Citat:
degojs:Jesse Liberty: "Programming C#", strana 493:
When two assemblies have different major or minor numbers, they are considered to be incompatible. When they have different build numbers, they might or might not be compatible...

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.


Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan, sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv… - Z.Đinđić
 
Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042



+4631 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase31.07.2004. u 11:29 - pre 241 meseci
Citat:
mmix: 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.


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

Citat:
-zombie-*: 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?

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.

Citat:
Reljam- 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.


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.

Citat:
Dragi Tata: 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.


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.
Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan, sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv… - Z.Đinđić
 
Odgovor na temu

degojs

Član broj: 4716
Poruke: 5096



+51 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase31.07.2004. u 11:53 - pre 241 meseci
Citat:
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...


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.)
Commercial-Free !!!
 
Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042



+4631 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase31.07.2004. u 12:09 - pre 241 meseci
Citat:
Reljam: 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.


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.

Citat:
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)

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

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan, sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv… - Z.Đinđić
 
Odgovor na temu

Dragi Tata
Malo ispod Kanade

Član broj: 1958
Poruke: 3906
*.bos.east.verizon.net



+6 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase31.07.2004. u 20:42 - pre 241 meseci
@zombie: Ako te interesuje inlajniranje kod C++a, obavezno pročitaj ovaj člančić Herb Suttera:
http://www.gotw.ca/gotw/033.htm
IOCC
 
Odgovor na temu

srki
Srdjan Mitrovic
Auckland, N.Z.

Član broj: 2237
Poruke: 3654
..-chandran.sbs.auckland.ac.nz



+3 Profil

icon Re: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase02.08.2004. u 02:26 - pre 241 meseci
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.
 
Odgovor na temu

[es] :: .NET :: Pozivanje non-static promenljivih koje cuvaju podatke iz druge klase

Strane: 1 2 3

[ Pregleda: 7316 | Odgovora: 44 ] > FB > Twit

Postavi temu Odgovori

Srodne teme
Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.