Nedostaci objektno orjenitisane metodologije, i ima li ih uopšte?

E, konacno sam se docepao svoje radne masine i kompajlera i sad mozemo konkretno da razgovaramo



E, ko sve nema MVP danas Necu da napadam coveka, ali ovo mu nije jedini omasaj na tom blogu (btw, okaci link sledeci put da ne moram da ga jurim). Ja mozda ne znam sve nijanse CLI C++-a, ali znam kako funkcionise CLS type system i u isti ne mozes da uteras free-f-ju.

Elem, sledeci kod:



je proizveo DLL koji sam zakacio za poruku. Ako pogledas metadata blok i izboris se sa gomilom djubreta koju je C++ nabacao unutra, videces da MojaFunkcija nije free f-ja, ona je deklarisana u IL-u kao:



dakle privatni staticki metod privatne klase <Module>. I to je nacin na koji rade "free f-je" u C++/CLI-u, kompajlerskom prevarom, sve su staticke metode ove klase a namespace se simulira dot-separacijom u samom imenu metoda. Jel sad treba i dokaz da ovu "free-fju" mogu da pozovom preko refleksije u C#-u sad kad znam u kojoj klasi je? To sto je C++ kompajler mufte sve markirao kao private da sakrije svoju prevaru od ostalih CLS compliant jezika ne znaci da mu se ne moze doakati.

Kad pogledas implemenatciju GCKlasa::Poziv() dobices sledeci kod poziva staticke metode:


Q.E.D.



Jbga, ne mogu da nadjem taj post, mozda vise i nije online, u svakom slucaju bilo je to jos u doba nastanka CLSa i radilo se o organizaciji GC-a i vezivanju root-va kreiranih objekata za tipove klasa, sto free f-je ne bi imale pa bi za njih morao da se radi posebni GC model sto bi isti usporilo pa su free f-je izbacene iz CLS-a jer ionako istu funkcionalnost postizes sa static metodama, i da je slicna prica vazila i za Javu, to je sve cega se secam. U principu i nije toliko vazno, necu se opirati mnogo.




Slazem se, multiple dispatch ne funkcionise automatski i jeste ogranicenje OOPa, ali ne vidim ni kako bi mogao da radi jer je totalna antiteza polimorfizmu (tj da vazi ono sto ti hoces, da je OO baziran na free f-jama, onda polimorfizam ne bi radio)
Bar koliko sam ja vidjao do sada, pribegavanje multiple dispatch-u je uglavnom bilo posledica loseg OO planiranja i adhoc razvoja sto je izmedju ostalog i tvoj primer. Vidis samim tim sto si uveo raznorodne operacije (kako rece, uvrnuto sabiranje ) nad istim operatorom+ uveo si sa OOP stanovista da klase D1 i D2 modeluju objekte cija + operacija ne potice iz base klase i samim tim + operator vise ne pripada u base klasi niti moze da se koristi polimorfno, pride (mada ne toliko vazno za ovaj primer) uveo si da + vise nije asocijativna operacija (sto je inace razlog zasto se operator "lepi" za levi operand).

Sve je ovo moglo da se organizuje i drugacije i ne bi ti trebao multiple dispatch i to je do sad uvek bila situacija i sa ostalim ozbiljnijim multiple dispatch problemima.


PS: Zaboravih da okacim DLL, evo ga sada.

_{[Ovu poruku je menjao mmix dana 20.10.2008. u 14:52 GMT+1]}

---

Gde ti covece pitas o nedostacima "objektno orijentisane metodologije"! Kao prvo ne postoji nista sto se zove "objektno orijentisana metodologija" i nigde to tako nije definisano, moze biti nacin misljenja i jos po nesto drugo ali nikako metodologija, metodologija je waterfall, agile, itd., a kao drugo o tim nedostacima se raspravlja u ozbiljnim softverskim i naucnim krugovima, dakle trebalo bi ovde ref. na radove sa konferencija i ozbiljnih (ISI) casopisa o paradigmama softvera da bi se o tome ozbiljno moglo raspravljati, a ne ovde na forumu na kom se raspravlja od kobasica do lokomotive.

Miljane, ok shvatio sam poentu. Posto CLR to odradjuje preko tog modela,
sta hoces sa time da kazes, da model free f-ja ne valja ili da je to jedini
ispravan model? ;)
Izgubio sam nit diskusije.

Sto se tice gc-a takodje je moguce da su gc pravili oko modela, ali sta sa time
hoces takodje da kazes? Pokazao si da clr implementira free f-je kao static metode.

Sto se tice polimorfizma, on ti je prosto mogucnost da proturis razlicite tipove podataka
kroz isti interfejs. Imas u sustini dve vrste, polimorfizam izgradjen na hijerarhiji
klasa i polimorfizam u f-onalnom izgradjen na bilo kojim tipovima koji se zove jos i genericko
programiranje u OO terminologiji. I to je sve. Ogranicenje polimorfizma
na samo jedan parametar ne znaci opet da je to jedini ispravan nacin i da su svi
slucajevi kad dodjes do potrebe da radis dispatch na vise od jednog parametra
dizajn error. Upravo suprotno mislim ;)


Pozdrav!

Pa ni jedno ni drugo, procitaj thread opet . U osnovi ti si tvrdio da CLR podrzava free f-je zato sto ti CLI C++ dozvoljava jezicku konstrukciju free f-je, i kao dokaz si citirao blog onog nesrecnika. Ja sam ti dao konkretan dokaz da free f-je ne postoje u CLSu, a sve kao deo price zasto Java i CLS nemaju free-fje. Obrati paznju na casu


Opet, ovo je deo price o tome zasto Java i CLS nemaju free-fje, ovaj deo price nije posledica, vez jedan od uzroka. Ali kao sto rekoh malopre, ne mogu da nadjem dokaz za ovo, pa ko da nisam ni rekao.


Mocan ovaj wiki Zapravo imas dosta vrsta polimorfizma, ali onaj koji nas interesuje u multi-dispatch prici je inheritance ili subclassing. To je onaj koji bi bio unisten sa multi-dispatchom, zbog cega ga i nemas u modernim OOP jezicima, a kao sto ti volis fre f-je i multiple-dispatch, tako ja volim svoj subclassing i koristim ga mnogo mnogo vise nego sto bih ikad koristio multiple-dispatch. Sa obzirom na to da samo Lisp ima automatski multiple-dispatch rekao bih da se i vecina ostalih slaze sa tim vidjenjem.


Ajd se prvo raspitaj sta je metodologija pre nego izneses ovako tvrd stav. OO itekako jeste metodologija, samo nije metodologija upravljanja softverski projektima sto su waterfall i agile vec metodologija modelovanja i izrade softvera. I ne vidim zasto se ovde ne bi vodila rasprava o nedostatcima OOP-a i zasto ES nije ozbiljan softverski kruzook . Mi svi koristimo OOP u realne svrhe i vecina nas prehranjuje porodice time, i smatram da je nas stav o tome vazniji od onoga sta o OOPu misle teoreticari programskih jezika koji o tome teoretisu troseci drzavne grant-ove. Jer vidis, na kraju krajeva, ljudi kao sto sam ja ce dati konacni sud o tome na sta ce firma da potrosi pare a zakon trzista ce odraditi ostalo, i iako se ja trudim da imam otvoren stav prema nadolazecim teorijama i da prepoznam nesto upotrebljivo (citaj profitabilno) u tome, isto tako imam uvid u to kako funkcionise taj akademski svet i kakve se sve gluposti i "cuda od tri dana" izmisljaju da se opravda trosenje grantova.

---

Miljane, malo je verovatno da su dizajneri c# i java jezika mislili na run time platformu
kad su pravili jezik. Mislim da je stvar upravo suprotna.

Tu uporno tvrdis da je nedostatak free f-ja posledica neke realne implementacije
i zbog toga potrebe. Kazem ti, nema nikakve razlike izmedju free, static member
i member f-je. Jedina razlika postoji kod closure f-ja zato sto se one
pakuju zajedno sa argumentima, pa ili se implementiraju kao run time generisani kod
ili se takva f-ja pakuje u strukturu koja vezuje parametar i f-ju.
No ni to nema neke veze sa gc-om, mada ako je platforma tako
zamisljena naravno verujem ti da ima mogucnost optimizacija
koje se koriste.

malo u off : no sa pojavom multicore procesora tesko da ce ikada
bilo kakav threadovani gc skalirati bolje od dobre stare rucne alokacije ;)
Zamisli samo u netu gc mora da zaustavi threadove, pa da muvne memory
blokove pa da izapdejtuje sve reference + sve ostalo sto
standardan gc mora da uradi. To znaci zbogom performanse i korovi ;)
[end off] ;)

Sto se tice polimorfizma, da wiki mora da bude tu, kako bi inace usaglasili terminologiju ;)
Sto se tice vrsta polimorfizama, koje su to druge u programiranju?
Sto se tice multiple dispatch tu se ne slazemo ocigledno ;)


Pozdrav!

@mmix: upravo o tome govorim, ljudi na ovakvim forumima opsteg tipa gde sa raspravlja i o kobasicama i svemu i svacemu razgovaraju o nedostacima neke "metodologije" koja je pre svega zasnovana na teoriji. Sta je metodologija, pogledaj ovde: http://bs.wikipedia.org/wiki/Metodologija. Vi mozete da raspravljate o nedostacima neke konkretne tehnologije, ali o nedostacima cele jedne paradigme raspravljati ovde bez ikakvih referenci je ili smesno ili imate previse slobodnog vremena u prehranjivanju vasih porodica ovim "metodologijama". U svakom slucaju je neozbiljno da neozbiljnije ne moze biti, cak i za jednu (tehnoloski) smesnu zemlju kao sto je ova. Imate strucne forume i mesta gde se moze argumentovano raspravljati o tome. To je moje misljenje a svakako nije ni ovde zabranjeno raspravljati o naslozenijim naucnim i usko strucnim teorijama, to svaki nas covek voli da radi.

I ES je strucan forum*. Ima raznih oblasti, ali se ljudi obicno koncentrisu oko nekoliko onih koje ih interesuju. Madzone ne treba mesati sa tim ;)

*Druga je stvar sto je prosecna strucnost opala zbog porasta kvantiteta.

---

Milase pusti ti teoriju. Po teoriji idealno programiranje je funkcionalno
iako u praksi sa time ne mozes da napravis ni prost IO.
Po teoriji ne valja ni goto iako se ostavlja u jezicima na ovaj ili onaj nacin.
Jedno je teorija drugo je praksa. Svi jezici koji se se cisto pravili
po teoriji nikada nisu uspeli u praksi. Pragmaticni jezici
koji su zapostavili teoriju na ustrb mogucnosti da se nesto
i prakticno odradi sa time su uspeli. Nije ni cudo sto danas
sve imamo jezike sa viticastim zagradama umesto begin end
blokovima ;)

I na kraju prakticari ce pre videti sta ne valja u teoriji nego teoreticari ;)

Pozdrav!

edit: i da ako si bez blama izjavio kako je diskusija neozbiljna sad bi red bio
da argumentovano ukazes na neku neozbiljnost ili ne?


_{[Ovu poruku je menjao Branimir Maksimovic dana 21.10.2008. u 14:50 GMT+1]}

Dizajneri C#-a mozda i nisu (mada indirektno jesu posto je na jezik drasticno uticala Java), ali dizajneri Java runtime-a i CLR-a apsolutno jesu jer oni zapravo sadrze kljucne sisteme na koje se ovi jezici oslanjaju (posto svi CLS jezici a i Java ne proizvode native vec intermediary bytecode). Ako CLR ili Java runtime ne podrzavaju neku tehniku ili metodu onda jezik moze ili da je ne implementira (kao sto C# ne implementira f-je) ili da nekom prevarom napravi workaround (kao C++).


Pa ne tvrdim vise zar nisi procitao, ne mogu da nadjem dokaz za to sto sam rekao i odustao sam od te tvrdnje.

A i GC se mozda ne skalira tako lepo kao manual alloc, ali se zato memory leakovi bolje skaliraju sto je narocito vazno kod 24x7 core servisa.

Pa pogledaj wiki , ionako nisu vazni za ovu raspravu



@milas:
Pa eto vidis, ja kao nas covek volim da analiziram i raspravljam o najslozenijim naucnim i usko strucnim teorijama (sto OO inace nije) jer mi je mama rodila mozak da ga koristim. Ako tebe na neki nacin nervira sto sam se ja drznuo da to radim iako nemam dva post doktorata u polju i nisam izmislio svoju paradigmu, onda mozes slobodno da ignorises moje postove; medjutim ono sto sigurno ne mozes je da odredjujes o cemu ce ko da raspravlja i kakva ce pitanja da postavlja. I ovaj sajt mozda jeste raznorodan, ali forum u kome sad pises se zove "Art of Programming" i u njemu se ne raspravlja o kobasicama. Na kraju, samo za tvoju informaciju, cilj nijedne rasprave na ovom forumu nije da se doprinese nauci, niti su postovi naucni radovi da moraju da imaju reference, citate i parafraze. Cilj je da se razmene iskustva i da se dodje do nekih tehnickih (inzenjerskih ako hoces) zakljucaka. Ako mislis da neki argument nije osnovan i da ti znas bolje, a ti doprinesi svojim argumentom umesto sto stojis sa strane i pis*s na nas.

A inace, ovaj link ti je carski Odmah sam se prisetio mladosti i idiotluka koji vlada nasim akademskim svetom. Zasto jednostavno kad moze ekstremno komplikovano. Ako ces vec da nas ucis sta je metodologija onda bar citiraj iz onog jezika koji ga je izmislio i shodno bransi koju kritikujes, ne ova nasa bulaznjenja filozofa o tome sta je filozofska metodologija.

---

Miljane, sto se tice c++ na clr mislim da je to jeftin trik da se privuku c++ programeri ;)

Sto se tice gc, verujem ti to sto si rekao.

Pozdrav!

Ne bih se baš složio da je to samo jeftin trik da se privuku C++ programeri, već rešenje razmišljanja o tome kako da se ne baci u vodu postojeći C++ kod i lagano prebaci kompletno u "clr:safe" režim. A drugo, dizajnerima biblioteka se stavlja u ruke možda jedan od najmoćnijih i najfleksibilnijih (potencijalno i najopasnijih) jezika trenutno.

@Miljan, mmix
I ovako i onako isto "košta" i free f-ja i statička i mislim da niko nije ni tvrdio drugačije, ali je fino imati free f-ju na nivou source-a kako se, na kraju krajeva, nebi petljao s tim da kreiraš klasu, kako bi stavio par f-ja unutra, a usput možeš da nabasaš (vremenom) i na neku koaliziju imena klasa.


Što se tiče polimorfizma, ne vidim zašto je loše imati mogućnost (ili zašto to ruši OO koncept) da polimorfno posmatraš i argumente, a ne da samo objekat pozivajuće f-je bude povlašćen u tom smislu. Tako da, multiple dispatch je zapravo odlična stvar u datom trenutku. Mislim da nema onoga kome u životu nije zatrebao barem double dispatch u nekom OO jeziku.
E sada, ne znam da li biste se složili ili ne, ali ako je negde moguće uvesti multiple dispatch (u vidu biblioteke) na najelegantiji način, onda je to baš C++. Probajte da napišete multiple dispatch u nekom drugom mainstream OO jeziku danas, bilo bi to poprilično teško (a da usput postignete da skoro nema ikakvog nepotrebnog performance hit-a).

Pa sad nisa mbas siguran da postojeci c++ kod mozes da koristis bez problema
gde ti gc pomera memoriju ispod nogu ;)

No verovatno se klasicna alokacija tamo ne kolektuje.
U principu u braku izmedju c++-a i cli-ja ne vidim nista osim problema.

A da je c++ veoma opasan u clr environmentu to svakako da ;)

Pozdrav!

Što se tiče same teme, evo, funkcionalno programiranje se polako javlja u nekim OO jezicima radi elegantnijeg zapisa nekih konstrukcija koje su se vremenom razvilie, ali ne vidim da će se OO paradigma ugasiti u potpunosti ikada jer je to verovatno za sada "najprizemniji" način opisivanja svakodnevnih tokova i problema.

--
@Branimir
Ma nema nikakvog problema što se tiče sprege native C++ -> C++/CLI. Uz malo pažnje ne može ništa preterano da pođe naopako.
Tamo gde treba da koristiš postojeći C++ kod, tamo ćeš pored marshalling-a i pinnovati objekte, tako da ne vidim što bi GC onda bio smetnja.

Ok, jednostavan primer, pseudo code, sve metode su subclassing polimorfne:


Sta ce se desiti? Inheritance/subclass polimorfno, dobices "A => Base", ako ukljucis doubledispatch zaobicices inheritance polimorfizam i dobices "A", a ovo je samo double dispatch i to u prvom stepenu nasledjivanja , sta cemo sa nekom klasom B koja nasledi A i doda jos jedan virtuelni metod?. Fora je sto sa implicitnim single dispatch u vecini modernih OO jezika mozes da kontrolises polimorfizam deklarativno i da odredis sta jeste a sta nije polimorfno, sa dodatnim dispatchom tu mogucnost vise nemas i kompajler/runtime mora da da prednost multi-dispatchu nad inheritance polimorfizmo. Govorimo naravno o automatskom dispatch-u bez potrebe za rucnim pattern match-om. Sve to lepo izgleda na papiru ali u praksi bi napravilo dar mar.

Mozda je to tacno da nekome bas zatreba multiple dispatch kao jedini moguci izlaz iz problema (meni je zadnji put zatrebalo pre par godina u jednom Delphi programu), ali u toj situaciji i u svim modernim OO jezicima uvek mozes sam da odradis pattern match i da pozoves odgovarajucu implementaciju; ali ne vidim te sporadicne potrebe kao razlog da se generalno upropasti inheritance i staticko/vTable linkovanje. Ako u pricu ubacis automatski multi-dispatch onda vise nijedan poziv metoda ne moze biti staticki/vTable linkovan vec svaki poziv MORA da prodje runtime matching pre poziva, sto je jos grdje od dinamickih jezika bar u smislu performansi.

---

Pitanje je sta je ispravno? Sa obzirom da si specifikovao slucaj
kad je kombinacija D,D ispravno bi bilo da se pozove ta f-ja
a ne varijanta kad drugi parametar odgovar Base ili nekoj drugoj
izvedenoj.

Evo recimo nije me mrzelo da implementiram najprostije
multi methods preko rtti-ja i variadic argumenata.
Izveo sam jos jednu klasu kako bi demonstrirao o cemu se
radi.

Kad se dispatch radi samo na jednom parametru polimorfizam
i ne funkcionise kako treba zato sto specifikacija
za D, D kombinaciju nikada nece biti pozvana.

Medjutim, u slucaju multi metoda cak i izvedena klasa
ce pozvati D,D kombinaciju kada je drugi parametar D
pod uslovom da napravimo takav model da se multi metodi
nasledjuju u slucaju da nisu overridovani za datu klasu.

U slucaju kad je drugi parametar najizvedenija klasa
a sa obzirom da sam uzeo model da samo Base mozemo racunati kao virtuelni
parametar (recimo predlozeni c++ model ukljucuje keyword virtual
uz parametar) f-ja koja najvise odgovara onda biva
ona sa Base drugim argumentom, pa kombinacija D, A ili A, A
zove D, Base.
E sad mozemo uzeti i model po kome je najvise odgovarajuca
f-ja koja najvise specijalizira izvednu klasu pa to moze
biti i D, D




No ovo je samo jedan primer kako to moze biti implementirano
.



E sad, ni ovo ti ne stoji. Sto ne bi mogao da specificiras
free standing f-ju i njen virtuelni overload.
Ne vidim nikakvih problema u tome.
Bilo bi sintaksno dovoljno naznaciti koje f-je overriduju,
tj implementiraju genericku f-ju a koje ne.
Izmedju ostalog imas CLOS i Dylan i jos neke jezike
koje imaju multi methods pa vidi kako je to tamo
odradjeno.




Pazi, nije bas sporadicna potreba. Ne mozes sve moguce f-je
strpati u fiksni interfejs jedne klase,
a pogotovo ne kad nisi autor i nemas prava to da diras.
Evo ti primer, odlican
clanak Scott Meyers-a u vezi toga.
http://www.ddj.com/cpp/184401197

Sto se tice same implementacije multi metoda linkovanje vazi
samo za staticki kompajlirane jezike. Medjutim cak i u tom
slucaju mozes generisati staticke tabele f-ja na osnovu
informacije iz object fajlova u vreme linkovanja. Efektivna implementacija
moze biti odradjena tako da ima konstantni run time cost
ili ne kao u ovoj mojoj naivnoj implementaciji.

Pozdrav!

edit: jos jedan clanak u korist ovog argumenta
http://weblog.raganwald.com/20...uch-of-good-thing-not-all.html
http://www.gotw.ca/gotw/084.htm

<sub>[Ovu poruku je menjao Branimir Maksimovic dana 24.10.2008. u 08:45 GMT+1]

[Ovu poruku je menjao Branimir Maksimovic dana 24.10.2008. u 08:53 GMT+1]</sub>

Nisi trebao da se maltretiras jer to nije bio problem (opet ti promakla nit ). Nije problem koji od ta dva je ispravan, nek bude ispravan taj koji ti kazes. Problem koji je demonstriran je da multidispatch i inheritance subclassing nisu kompatibilni jer konkurisu za isti poziv i da bi multi-dispatch uopste radio subclassing inheritance mora da se "povuce". To mozda tebi izgleda super (ne znam koliko koristis sublassing), ali meni ne izgleda uopste privlacno.


Opet se nismo razumeli, ne govorim o tome. U single-dispatch scenariu kompajler ima informaciju o svim detaljima tog dispatch-a i polimorffizmu jer to potice iz deklaracije, za svaki dodatni stepen dispatch-a te informacije vise nema, glupavo receno ne mozes konsultovati dva v-table-a i moras da radis pun runtime pattern match. Ako to radis onda subclassing inheritance vise nema nikakvog smisla i jezik zaista mozes da svedes na ono sto ti predlazes a to je dinamicki proceduralni nivo jer kad pogledas malo dublje tvoje klase vise nisu nista sem strukture sirovih podataka.
Ne znam kako CLOS i Dylan to resavaju, da u isto vreme imas inheritance polimorfizam i multidispatch polimorfizam i da se oni ne kolju, pa daj neki primer, valjda cu prokapirati



Haha, a imas pravo da dodavanjem extra multidispatch fja/metoda totalno poremetis osmisljeno funkcionisanje tih klasa? Vidis automatski multidispatch je retroaktivan, pa se promene ne odnose samo na tvoj kod, odnose se i na sve pozive koji vec postoje u tim klasama ciji nisi autor i koje ne smes da diras. Ako sklonimo sujetu programera na stranu (ono, niko ne moze da menja moj kod jer sam ja List<superlativ>) obicno postoji dobar razlog zasto je funkcionalnost enkapsulirana tako da ne mozes da je promenis kroz subclassing.

A za clanak, pa ima dosta stvari sa kojima se u tom DDJ clanku ne slazem, a najvise u vezi enkapsulacije. Iz nekog razloga skoro svi hardcore C++ programeri imaju zesci animozitet prema enkapsulaciji (pred velike ljubavi prema fjama ), valjda misle da ce sa njihovim kodom da bartaju samo drugi hardcore C++ programeri koji ce uvideti lepotu pa nema potrebe da se bilo sta 'skriva' . Realnost je mnogo surovija. Meni je npr enkapsulacija od velike koristi kako u modelovanju tako i u kontrolisanju sampiona.


Znaci ako dinamicki ucitas DLL u aplikaciju sa novim multidispatch implementacijama, one nece biti ukljucene? Sto ne? Uz najbolju volju ne vidim kako bi mogao da napravis univerzalni automatski multidispatch a da nema pun runtime pattern match.Ti to mozes malo da optimizujes kroz neko type indeksiranje, ali ne vidim mogucnost za konstantni runtime cost.

---

Tvoj argument da multiple dispatch iskljucuje single dispatch ne stoji.

Oba mogu koegzistirati zajedno. U kontekstu poziva single dispatch-a instanca.method()
radio bi se single dispatch, a u kontekstu genericmethod(instanca) radio bi se multiple
dispatch.
Takodje dao sam primer kako bi subclassing inheritance mogla da funkcionise.
Jednostavno kao i za single dispatch. Izabere se najspecijalizovaniji oblik
za izvedenu klasu i sa time napunis dispatch tabele. Nije nikakav problem.
To ti je isto sto radi i single dispatch.

Sto se tice tvog argumenta za linkovanje i slicno to ti uopste ne stoji.
Evo recimo imas konkretni proposal kako to da se implementira u C++
sa konkretnom sintaskom sa konkretnim izmenam u modelu i linkeru.
http://www.research.att.com/~bs/multimethods.pdf

Sto se tice agrumenta za fiskiranje interfejsa opet si okrenuo pricu naopako
i nudis pricu tipa c++ programeri ovo ili ono.
Ovo:


Ne razumem kako bi se ovo razlikovalo od toga kad overridujes neku f-ju iz bazne klase.
Sa obzirom da se behavior menja i u jednom i u drugom slucaju? To je ono sto hocemo, zar ne?
Medjtutim sada si proponent glomaznih i fiksnih interfejsa za koje se top strucnjaci
u ovoj oblasti slazu da su stvar proslosti.


Sve u svemu. Tvoji argumenti se sastoje iz dva dela. Jedan da je to neko narusavanje
OO principa , sto ne stoji zato sto je single dispatch samo specijalizovani slucaj mutli dispatch-a,
a drugo da je to tesko odraditi u praksi. No evo naveo sam konkretan predlog za staticki
kompajliran jezik i to sa konstant time izvrsavanjem, dakle ipak moze.
Sto se tice dll-ova nema veze, ti ionako prvo linkujes tako sto znas kako ce ti dll pozivi izgledati.
To sto se linkovanje odradjuje u run time-u ne sprecava kompajler
da izgradi tabele u kodu i pre toga.
Jedini slucaj kad to ne radi je kad ti rucno ucitas dll pa jedini interfejs koji imas je C api.
Ali tu ti ne radi ni single dispatch onda ;)
No mikrosoft ima com standard binarni interfejs pa com single dispatch radi ali to nema veze
sa ovim sto pricamo.

Pozdrav!


_{[Ovu poruku je menjao Branimir Maksimovic dana 24.10.2008. u 20:40 GMT+1]}

Mi se bas ne razumemo. Ne iskljucuje single dispatch (koji takodje radi pattern match) vec iskljucuje inheritance polimorfizam koji ne koristi pattern match vec koristi indirektni poziv preko vTabele. Nema veze koju implementaciju koristis inheritance polimorfizam moze da postoji samo do trenutka dok se ne pojavi metod sa matching runtime patternom i onda mora da se povuce inace multidispatch ne bi radio, to je jednostavno cinjenicno stanje i to sam ti dao u onih par linija koda, definitivno ne mogu oba metoda biti pozvana u isto vreme i stvarno ne vidim kako mislis da je to resivo?
Takav parcijalni inheritance je veoma opasan jer ne mozes da se pouzdas u to da ce raditi svoj posao cime takodje celokupan encapsulation pada u vodu jer ne mozes da zadrzis kontrolu nad tim kako ce tvoja klasa funkcionisati.

I taj clanak o openmethods je ok, i sve to stoji i nista o tome nisam ni pricao (a i ako pogledas u ovom sistemu vazi da dispatch gazi inheritance kroz om-tabelu). Inace, problemi na koje sam ja hteo da ti ukazem su lepo opisani u poglavlju 5 (Dynamic Linking). A sto se tice implementacije i performansi, zaboravljas da tokom runtime-a moras pri pozivu nekako da lociras poziciju unutar om-tabele, taj deo koda je patternmatching i mora da se uradi prilikom svakog poziva i progresivno je sporiji sa velicinom om tabele, nije fiksan.


Ma dobro, to je bilo zezanje, mada donekle. Izvini ako te to pecnulo, nije mi bila (zla) namera, ali niste ni ti ni Scott ni prvi ni poslednji C++ guru-i koji mi prodaju tu pricu. I sa teorijskog stanovista to zvuci veoma sareno i obecavajuce, ali nije (citaj dalje). I ja nisam proponent glomaznih interfejsa (mada fiksnih jesam) niti oni moraju da budu glomazni vise nego sto je to neophodno za njihovo zaokruzeno funkcionisanje, ali ta tvrdnja da si ti povecao enkapsulaciju i resio se glomaznog interfejsa time sto si metode prebacio u non-member f-je je naivno, jesi smanjio interfejs ali si povecao kolicinu spagheti-koda u programu i iz logickog OO koncepta klase kao zaokruzene celine si izbacio neku funkcionalnost kojoj je tu mesto (da totalno zaboravimo na neke nevazne zivotne olaksice kao sto je intellisense). I kad procesaljas kroz ceo sors, glomazni interfejs je i dalje tu samo sto ga vise ne koristis kroz instancu vec kao set slobodnih f-ja.


Razlikuje se utoliko sto kreator klase kontrolise access modiferima sta mozes i ne mozes da overridujes i time stiti svoju enkaspulaciju. Potreba za multi-dispatchom se bar iz mog iskustva pojavljuje kao rezultat frustracije sto nesto nisi mogao da odradis kroz subclassing a bas ti je zapelo za oko ili je autor klase bio kratkovid i pisao je kao da je sealed a nije. Pa ajde da zeznemo autora klase i da ga ispreskacemo . Time po meni prizivas djavola i trazis probleme.

subclassing i inheritance polimorfizam je u biznis aplikacije doneo modeling i pouzdanost tih modela, kad bih odustao od toga morao bih sebe da lisim pouzdanosti koju mi donosi:
- da znam uvek sta ce se i kako pozvati
- da znam pouzdan i stabilan nacin na koji se funkcionalnost i definicija prosiruju i da je to uokvireno u neke celine
- da niko sa strane (out of scope) to ne moze da izminira
- da determinizam poziva ne zavisi od toga koji moduli su ucitani u domen
- vezano sa tim, da mogu da u domen ucitam nasledjenu klasu bez da poremetim rad postojeceg koda.
- da zadrzavam enkapsulaciju i stavim korisniku klase (programeru) do znanja gde mu NIJE mesto.
- ako bas, bas, bas, BAS mora da se odradi neki multi-dispatch, skoro svi OOP jezici to omogucavaju kroz rucni patternmatch
- i last, but not least, da korenita promena u zahtevima postojeceg objektnog modela nece moci da se adhoc zakrpi vec ce izazvati obavezan povratak OO modela za drawing desk.

I ja pretpostavljam da ovo poslednje tebi najvise bode oci, i meni je svojevremeno (sta me cima ovaj projektant kad ja to mogu da zakrpim za 10 minuta), ali od kad sam vise poceo da se bavim arhitekturom i nekim drugim parametrima kao sto je pouzdanost, stabilnost, odrzivost, TCO, itd, iskreno manje eksperimentisem i vise kontrolisem sa cime se eksperimentise u projektima od kojih zavisi biznis firme. Sa tog stanovista multi-dispatch mi ne donosi nista fundamentalno korisno i nezamenljivo, samo potencijalne glavobolje i pored toga sto je mocniji i neke stvari resava bolje nego mainstream inheritance poly. U jednoj prosecnoj viseglavoj ekipi uvek ima sampiona, i uvodjenje multi-dispatcha (jos sa free f-jama) u takvu sredinu mi deluje kao davanje Hilti busilice maloj deci, nista dobro iz toga ne moze da izadje.
Tako da se vratimo na temu, to sto nema multi-dispatch-a u mainstream OO jezicima jeste nedostatak, ali je nedostatak sa kojim cu se rado pomiriti i sve i da ga ubace kroz dodatne sintaksne konstrukcije necu ga koristiti.

---

Da pocnem, jeste ne razumemo se.
Single dispatch moze postojati zajedno sa multiple dispatch-om
tako sto oba mogu koegzistirati. Obe funkcije zasigurno ne mogu
biti pozvane ali ima slucaja kad ti odgovara jedno ili drugo.
Nema nikakvih problema da se postojeci jezik nadogradi generickim
f-jama ali isto tako nema razloga da se eliminisu metodi zbog toga.

Sto se tice c++ predloga problemi o kojima si ti govorio sam
shvatio u smislu teskoca u pogledu implementacije samog
dispatch-a u okviru linkovanja,
a ovaj clanak govori o problemima detekcije gresaka
tj ambuigitija u slucaju kada vise f-ja odgovara jednoj
kombinaciji i mogucem resavanju istih.

Sto se tice spageti koda, i free f-ja, argument ti je da
na taj nacin razbacujes interfejs na sve strane umesto da
stoji na jednom mestu.
Propustio si da primetis koje su prednosti toga.
Prvo ne moras da linkujes i ucitavas kompletan kod koji ti ne treba.
Drugo ne moras da rekompajliras celu hijerarhiju radi dodavanja
jedne f-je. Trece programer mozda pise kastom kod koji samo
njemu koristi i nigde vise.

Sto se tice argumenta o menjanju ponasanja i razlici izmedju multi
metoda i single dispatch-a u okviru poziva virtuelnih
funkcija kazes sledece:


Pa ako stavis da je f-ja virtualna ne vidim nacina kako bi sprecio
nekoga da to overriduje ili ne?
Ako neces mogucnost da se radi multi dispatch napravis najobicniju
f-ju i pozoves je i nema override-a.
Nema cistih virtuelnih multimetoda ukoliko mislis da se to
separatno kompajlira i linkuje.
Dakle morao bi da napravis jednu virtuelnu i da je pozoves.
A cim si to imao na umu pretpostavio si da neko vec hoce da menja
ponasanje postojeceg koda zar ne?
Kako se to onda razlikuje od toga kad ti je member virtual?

E sad ono najbitnije, sto moram da citiram:


Doneo je odredjenu vrstu modelinga. Proglasio je podatak
za objekt, a objekte entitete koji mogu da aproksimiraju realne
objekte. Tacno, ali je uveo i nivoe apstrakcije i tehnike koji
zahtevaju daleko vise znanja nego sto je ranije bilo potrebno.



To u objektnom programiranju ne znas.
Sve sto znas je da saljes poruke nekim objektima
za koje ne znas ni kog su tipa.
Sve sto imas je interfejs koji se satoji iz mogucih
poruka datim objektima, a sta konkretno treba da se
desi nadas se po imenu;)


U okviru- OO hijerarhija jedini stabilan nacin da prosirujes
funkcionalnost je u oviru onoga koji je napravio dizajn.
Dakle ako prosirenje funkcionalnosti nije pokriveno dizajnom moras da menjas
postojeci kod.


dodavanje generic f-ja ne bi tu bio problem. one ionako ne bi imale prava
pristupa.



pa ovakvu garanciju nemas ni kod proceduralnih jezika.



to vec zavisi od dizajna


to neces postici tako sto ces onemoguciti korisniku da dodaje
f-je koje su mu potrebne.
enkapsulacija se ne narusava kodom koji ne razbija postojeci vec predstavlja
dodatak.


Ako cemo tako i OOP moze da se simulira kroz tabele pointera na f-je
i f-je koje za prvi parametar uvek uzimaju neku strukturu.


Povratak OO modela za drawing desk je priznavanje poraza,
a to kosta vremena i novca, pogotovo ako je veca aplikacija
u pitanju i pogotovo ako se klijentski kod oslanja na to.
Ne mozes back to scratch u svim uslovima.

No nisam siguran o kakvim hilty busilicama govoris.
Multi metodi i free f-je su prosto resenje da se sav
kod koji se razbacuje po razlicitim meotdama klasa
logicno organizuje i preuzme. Nema tu nikakvog narusavanja
necega jer te f-je nemaju prava pristupa podacima klasa,
a samim tim sto se sav pristup zasniva na pozivanju
metoda opasne su koliko i bilo koji kod, u bilo kojoj
drugoj metodi, bilo koje druge klase.
Pozdanost, stabilnost i odrzivost na koju se pozivas
zavisi upravo od ovoga o cemu pricamo.

Pozdrav!

edit:
sta bi onda rekao na AOP, mogucnost da patchujes kod na osnovu upita tipa
gde go metod pocinje sa tim i tim imenom izvrsi ovo pre ili/i posle
Ili tipa dodavanje metoda na klasu i slicno sto se radi u AOP-u ;)

ovo je opasno, a ne free f-je i genericki metodi ;)


_{[Ovu poruku je menjao Branimir Maksimovic dana 25.10.2008. u 06:03 GMT+1]}

Pa i nisam bas odusebljen AOP-om ali je to work in progress, pa pratim da vidim sta ce da se desi ;)


Pazi, mi ovako mozemo da se djroramo narednih godinu dana, poceo sam da spremam odgovore na tvoje odgovore na moje odrgovore... i provalio sam da opet pisem iste stvari. Cinjenica je da nista sto ti kazes nece promeniti moj stav i nista sto ja kazem nece promeniti tvoj, ali koliko vidim obojca smo izneli gomilu pro i cons za oba pristupa, tako da mislim da je vreme da se slozimo da se ne slazemo i da prepustimo citaocima da sami vide sta njima odgovara.

---