Tehát a nyelv nem nyújt megfelelő eszközt az öröklés kézbentartásához, a szerző bloatware frameworköket használ, a sztenderd Python dokumentáció pedig köztudottan egy áttekinthetetlen szemét, ami végső soron nem is lényeges, mert ő a kódkiegészítést akarja használni dokumentációnak – tehát a paradigma a szar.
A két beküldött blogmark között van egy kis kontraszt. Az előző azt mondja, hogy "Mixins: The Only Good Solution", míg ez pedig azt, hogy támogatás hiányában és adott körülmények közt eléggé meg tudják nehezíteni az ember életét.
Ha az adott körülmények azt jelenti, hogy egy névtérben sok függvény van, akkor valóban, de ez nem tudom, hogy mond bármit is egy nyelvi konstrukcióról. Egyszeres örökléssel vagy mezei globális függvényekkel is fennáll ugyanez a probléma.
Ha a globális névtér túl nagy lesz, akkor a lookup lassú lehet. Ez történhet ugye fordításidőben, illetve futtatás közben. Ha csak fordítás közben lassú (pl C esetén) akkor annyira nem probléma, ugyanakkor ha futásidőben, akkor már problémásabb. És minél nagyobb egy névtér, annál esélyesebb, hogy ütközés történik. Ez fordított nyelvek esetében annyira nem gond, mert a fordító tud figyelmeztetni, de dinamikus nyelveknél rengeteg hibát szülhet, amit nagyon nehéz lehet felderíteni. Ezért törekednek arra, hogy az egyes névterek minél kisebbek legyenek, hogy kisebb legyen az esély az ütközésre.
A két példád között azért elég nagy a különbség. Egy téglalap objektumot nem fogysz csak azért létrehozni, hogy kiszámítsd a területét, inkább sok más célra is fel fogod használni. Például átadod más objektumoknak, függvényeknek, hogy azok további műveleteket végezzenek vele, például átadod a view rétegnek, hogy kirajzolja a koordinátái alapján stb. Ha egy névtérbe csomagolod, akkor könnyebb átadni, nem kell törődni a típusával, csak hogy implementálja a kívánt interfészt.
Ha a globális névtér túl nagy lesz, akkor a lookup lassú lehet.
Igen, ezen már gondolkodtam múltkor is, miután válaszoltál a felvetésemre. OOP esetén nem tudom, mit lehet megspórolni, főleg többszörös öröklődés esetén, mivel tudtommal ilyenkor a "végső" meghívott metódus címét csak futásidőben lehet "kiszámolni". PHP esetében, ahol őrültség nem használni bármilyen kódgyorsítót, például APC vagy eAccelerator, amelyek bájtkódot készítenek, globális függvények használatakor le lehet optimalizálni úgy ezt a gyorstárazott kódot, hogy valamilyen módon közvetlen mutatót tesznek ezekre a függvényekre.
Többszörös öröklődés esetén is történhet a megfelelő függvény kiválasztása fordítás során. Persze nem tudom, mit értessz többszörös öröklődésen. A C++ féle öröklődést, amikor egy osztály több osztálytól örököl, vagy amikor van egy több lépcsős öröklődési lánc. Mindkét esetben valamilyen algoritmus teszi egyértleművé, melyik függvény lesz ténylegesen meghívva, és azt lehet egy mutatóval gyorsítótárazni (és a legtöbb futtatókörnyezet ezt meg is teszi).
Tehát a nyelv nem nyújt
Minden elismerésem.
A két beküldött blogmark
Ha az adott körülmények azt
Globális függvények
$teglalap_terulete = $teglalap->terulet();
Azaz itt a névtér az objektum neve.
Míg globális függvényeknél úgy nevezed el, hogy
teglalap_terulet()
,kor_terulet()
.Lookup
A két példád között azért elég nagy a különbség. Egy téglalap objektumot nem fogysz csak azért létrehozni, hogy kiszámítsd a területét, inkább sok más célra is fel fogod használni. Például átadod más objektumoknak, függvényeknek, hogy azok további műveleteket végezzenek vele, például átadod a view rétegnek, hogy kirajzolja a koordinátái alapján stb. Ha egy névtérbe csomagolod, akkor könnyebb átadni, nem kell törődni a típusával, csak hogy implementálja a kívánt interfészt.
Ha a globális névtér túl nagy
Öröklődés
Csalás
A $book->persist() eleve egy szörnyű megközelítés. De ezt kitárgyaltuk a minap egy másik témában :)
A rossz blogmark alá küldted
Óh,
Kérdés
Nem értem a kérdésed.
Talán a 9-es hozzászólás
Gyakorlatilag multiple