(PHP 5 >= 5.3.0, PHP 7)

Mielőtt a névterek használatáról beszélnénk, fontos megérteni, hogy a PHP honnan tudja, hogy a kód melyik névteres elemet kéri. Egyszerű analógia tehető a PHP névterei és a fájlrendszer között. Háromféleképpen lehet hozzáférni egy fájlhoz egy fájlrendszerben:

1. Relatív fájlnév pl foo.txt. Ez megoldja jelenlegikönyvtár/foo.txt ahol a currentdirectory az éppen foglalt könyvtár. Tehát ha az aktuális könyvtár az /home/foo, a név így alakul /home/foo/foo.txt.
2. Relatív elérési út neve, mint alkönyvtár/foo.txt. Ez megoldja jelenlegikönyvtár/alkönyvtár/foo.txt.
3. Abszolút útvonalnév, mint /main/foo.txt. Ez megoldja /main/foo.txt.

Ugyanez az elv alkalmazható a PHP névteres elemeire is. Például egy osztálynévre háromféleképpen hivatkozhatunk:

1. Nem minősített név, vagy előtag nélküli osztálynév, mint pl $a = new foo(); vagy foo::staticmethod(); jelenlegi névtér, ez megoldja jelenleginévtér\foo foo. Egy figyelmeztetés: a függvények és konstansok minősítetlen nevei globális függvényekké és konstansokká fognak feloldódni, ha a névteres függvény vagy konstans nincs megadva. Részletekért lásd: A névterek használata: visszaállás a globális függvényre/konstansra.
2. Minősített név, vagy előtaggal ellátott osztálynév, mint pl $a = új alnévtér\foo(); vagy alnévtér\foo::staticmethod();. Ha az aktuális névtér jelenlegi névtér, ez megoldja jelenleginévtér\alnévtér\foo. Ha a kód globális, nem névteres kód, akkor ez a következőre oldódik fel alnévtér\foo.
3. Teljesen minősített név, vagy előtaggal ellátott név globális előtag operátorral, mint pl $a = new \currentnamespace\foo(); vagy \currentnamespace\foo::staticmethod();. Ez mindig a kódban megadott szó szerinti névre bontja fel, jelenleginévtér\foo.

Íme egy példa a háromféle szintaxisra a tényleges kódban:

névtér Foo\Bar\subnamespace;

const FOO = 1 ;
függvény foo()()
osztályú foo
{
}
?>

névtér Foo\Bar;
tartalmazza "file1.php" ;

const FOO = 2;
függvény foo()()
osztályú foo
{
statikus függvény staticmethod()()
}

/* Nem minősített név */
foo(); foo::staticmethod(); echo FOO ;

/* Minősített név */
alnévtér\foo(); // feloldja a Foo\Bar\subnamespace\foo függvényt
alnévtér\foo::staticmethod(); // feloldja a Foo\Bar\subnamespace\foo osztályt,
// metódus staticmethod
echo alnévtér\FOO; // feloldása a Foo\Bar\subnamespace\FOO konstansra

/* Teljesen minősített név */
\foo\bar\foo(); // feloldja a Foo\Bar\foo függvényt
\foo\bar\foo::staticmethod(); // feloldja a Foo\Bar\foo osztályt, staticmethod metódus
echo\Foo\Bar\FOO; // feloldja a Foo\Bar\FOO állandót
?>

Vegye figyelembe, hogy bármely globális osztály, függvény vagy konstans eléréséhez egy teljesen minősített név használható, mint pl \strlen() vagy \Kivétel vagy \INI_ALL. ?>

A PHP az 5.3-as verziótól kezdve névtereket adott nekünk. Azóta lassú és heves vita folyik arról, hogyan használjuk ezt a névteret?
Néhány keretrendszer, például a Symphony, a Laravel és természetesen a Zend is alkalmazta ezt a technológiát.
Mindez többé-kevésbé belefért az MVC rendszerébe. Marad egy, valószínűleg örök vita: mi legyen az alkalmazás fő házassági párja - Modell és Controller?
Egyesek azt mondják, hogy a modellnek vaskosnak és kövérnek, vele együtt karcsú és vékony vezérlőnek kell lennie. Egyszóval - matriarchátus.
Mások éppen ellenkezőleg, úgy gondolják, hogy az irányítónak kell mindent irányítania és irányítania, tehát szilárdnak és jól tápláltnak bizonyul. És vele egy vékony, karcsú Modell, akinek az a feladata, hogy adjon és hozzon. Ez a patriarchátus.
Tehát melyik a jobb az MVC rendszerben? Patriarchátus vagy matriarchátus?
Nézzük ezt a demokrácián alapuló családi egység felépítése szempontjából. És hadd segítsen nekünk ebben a Névtér.

Nem szeretjük a vastag, nehézkes vezérlőket, amelyek, mint egy bika a porcelánboltban, összetörhetik az egész alkalmazást, ha figyelmetlen vagy.
A kövér modelleket sem szeretjük. Nos, ki szereti őket? Bizonyára méltóak a dobogóra!
Próbáljunk meg egy jó párkeresőhöz hasonlóan a Névtér segítségével harmonikus családot teremteni.

Először is hozzuk létre az alkalmazás vázát. Bármilyen banális is, legyen ez egy blog.

Létrehoztunk egy alapstruktúrát, ahol:

• A blog az alkalmazásunk tárolója;
• Nézetek és sablonok – nézetek és sablonok tárolása;
• Utility - megosztott könyvtárak tárháza;
• index.php - bootstrap szkript;
• Posta - itt kell megtörténnie a Controller és a Model családi idilljének.

Az index.php-vel minden egyszerű:

fut(); /* * index.php vége */

Meghatározzuk a szükséges útvonalakat, és létrehozunk egy automatikus betöltőt.
Az automatikus betöltő betölti a szükséges osztályokat, amelyek az osztálynévtérnek megfelelő mappahierarchiában helyezkednek el. Például a BlogPostServicesView osztály a Blog/Post/Services mappában lesz megkeresve.
És itt az első találkozás a Névtérrel.
Az index.php elindításakor létrehozzuk a Blog alkalmazás egy példányát, melynek osztálya a Blog/Blog.php fájlból töltődik be.
Nézzünk rá.

post = new Post();

) public function run() ( $this->post->view->all(); ) )//end class Blog
A Blog osztály létrehozásakor beillesztünk egy Post osztályt a Namespace BlogPost segítségével, és az automatikus betöltő betölti a Blog/Post/Post.php fájlból.

Valószínűleg ezt az osztályt vezérlőnek nevezhetjük,

view = new View();
) )//osztály vége Post

A Post entitás a következőket tartalmazza:

- magának az adatrekordnak a szerkezete - BlogPostEntitiesPostEntity.php

Vezérlőkéréseket kiszolgáló szolgáltatások - BlogPostServicesView.php (például az egyik szolgáltatás)
db = új DB();

)//end __construct public function all() ( $posts = $this->db->survey(); Contemplate::compose(array("header" => "fejléc", "main" => "fő", "footer" => "lábléc",), array("posts" => $bejegyzések, "title" => "Viper site") ) )//end class PostView
Az adatbázissal való interakciós rendszer - BlogPostRepositoriesDB.php - itt van, vékony, elegáns modellünk,

Csak add és hozd, és semmi több!
dbh = new PDO("mysql:host=localhost;dbname=test", $user, $pass, array(PDO::ATTR_PERSISTENT => true));

) catch (PDOException $e) ( echo "Hiba!: " . $e->getMessage() . "
"; die(); ) )//end __construct public function survey() ( $query_view = $this->dbh->prepare("SELECT * a bejegyzésekből"); $query_view->execute(); return $query_view- >fetchAll(PDO::FETCH_CLASS, "BlogPostEntitiesPostEntity" )//felmérés vége )//Db osztály vége
Ennek eredményeként olyan alkalmazásstruktúrát tudtunk létrehozni, ahol minden komponens jól kapcsolódik, miközben az osztályok egyértelmű elkülönítését értük el, ahol minden osztály a saját feladatát látja el. A vezérlőnk vékony és egyben erős. A modell illik hozzá. Ideális család!
És mindez a Namespace-nek köszönhetően.

Nem vitatom, sok esetben kényelmes a keret. De nézd, a névtér nem emlékeztet semmire?
Világos osztályok felosztása, szigorú és egyben rugalmas címtárak és osztályok hierarchiája, teljesen alárendelve a fejlesztőnek.

Nemrég beágyaztam a projektemet egy névtérbe, és belefutottam a megfelelő dokumentáció hiányának problémájába. Minden, amit sikerült megtalálnunk, nagyjából 2009-ből származik, és ez már majdnem 2012... A talált anyagban nagyon sok olyan nem működő hely van, ahol olyasmit használnak, ami a php jelenlegi verziójában nincs meg. Ezzel kapcsolatban szeretném megvilágítani ezt a kérdést.
Tehát mi az a névtér vagy névtér? A nagy wikipédia így határozza meg őket:

A névtér egy halmaz, amely az egyedi azonosítók (vagyis nevek) logikai csoportosítására létrehozott modellt, absztrakt tárolót vagy környezetet jelent. A névtérben meghatározott azonosító ehhez a névtérhez van társítva. Ugyanaz az azonosító egymástól függetlenül definiálható több helyen. Így az egyik névtérben definiált azonosítóhoz társított érték ugyanazt (vagy inkább eltérő) jelentéssel bírhatja (vagy nem), mint egy másik névtérben meghatározott azonos azonosító. A névtér-tudatos nyelvek szabályokat határoznak meg, amelyek jelzik, hogy egy azonosító melyik névtérhez tartozik (vagyis a definíciójához).wiki

Minden világos? Valójában egyszerű. Az 5.3-as verzió előtt csak két szóköz volt a php-ben - a global (amelyben a fő kód futott) és a local (amelyben a függvényváltozók voltak meghatározva).

Az 5.3-as verzió óta minden megváltozott. Most megadhatja a névterét, amelyben az osztályok, metódusok stb. létezni fognak.


Remélem kicsit világosabb lett.

Konkrétan ugyanígy neveztem el az osztályokat. Mivel különböző terekben vannak meghatározva, két különböző osztályról van szó, annak ellenére, hogy ugyanaz a neve. A fő szkript továbbra is a globális térben működik, itt semmi sem változott, osztályok és függvények továbbra is definiálhatók benne. Akkor mire valók a terek? Mindenekelőtt meg kell győződni arról, hogy ha valamilyen keretrendszert vagy könyvtárat tartalmaz, az osztályok nem írják felül a keretrendszer osztályait, és fordítva.

A névtérben definiált osztályok használatához a definiált teret a megfelelő helyre kell importálni a globálisba (én általában a fájl elején szoktam ezt megtenni, használd a use kulcsszót).

Figyelem: a php valamiért nem engedi a kulcsszó használatát használatállapotú blokkokban és hurkokban

Vegyük a példát a képekből, és implementáljuk kódban:

Figyelem: a névtér kulcsszónak a fájl legelején, közvetlenül utána kell lennie
fájl A.php
B.php fájl
Alternatív szintaxis lehetséges:
Javasoljuk, hogy minden névteret külön fájlban deklaráljon. Egyben ugyan lehetséges, de szigorúan nem ajánlott!
Most térjünk át a harmadik fájlra, amelyben a fő szkriptünk fog működni
index.php
Úgy tűnik, hogy ez előny, csak több kódot adnak hozzá, de ez nem teljesen igaz, kicsit tovább hozok egy példát egy autoload osztályra, amellyel a fájlokat osztályokkal összekötő sorok feleslegesek lesznek.
Most pedig nézzük az osztályainkat.

Figyelem: a hatókör felbontási operátor (::) használatával a php névterekben nem megengedett! Az egyetlen dolog, amire alkalmas, az a statikus osztálymetódusok és konstansok elérése. Először a névtérhez akarták használni, de aztán a felmerülő problémák miatt nem döntöttek. Ezért egy olyan konstrukció, mint az A::A::say(); érvénytelen, és hibához vezet.

A névterekhez a "\" fordított perjelet kell használni

Figyelem: A félreértések elkerülése érdekében ki kell hagyni ezt a karaktert, ha karakterláncokban használjuk: "\\"

A névterek egymásba ágyazhatók, tegyük hozzá az A.php fájlunkhoz:
az indexbe pedig a következőket írjuk:

Fontos szempont az álnevek használata az importált terekhez. Írhatsz A\subA::say(); Ön egyetért abban, hogy nehéz minden alkalommal teljes elérési utat írni a szóközökhöz, hogy ezt elkerüljük, bevezették az álneveket. Fordításkor a következő történik: az alias sub helyett A\subA lesz behelyettesítve, így az A\subA::say();

Mi történik akkor a globális térben meghatározott függvények meghívásakor? A PHP először azon a területen belül keres egy függvényt, ahol éppen dolgozik, és ha nem találja, akkor a globális hatókörbe lép. Annak érdekében, hogy azonnal jelezze, hogy globális függvényt használ, meg kell előznie egy fordított perjelet.

Az osztályok szóközökből történő automatikus betöltésével kapcsolatos problémák elkerülése érdekében a fájlrendszert a szóközök szervezéséhez hasonlóan kell megszervezni. Például van egy gyökérmappánk osztályaink, ahol az osztályaink lesznek tárolva, majd a tereink a következőképpen rendezhetők
osztályok\A\A.php
classes\A\sub\A.php (az alterület külön fájlba kerül)
osztályok\B\B.php

A PHP-nek van egy __NAMESPACE__ mágikus állandója, amely az aktuális tér nevét tartalmazza.

És most az automatikus betöltésről.

A lenti osztály nem az enyém, csak működőképessé tettem és egy kicsit javítottam, innen vettem.

Figyelem: Az osztályok betöltéséhez az osztály nevének meg kell egyeznie a fájl nevével!

".$file." in " .$filepath)); if (file_exists($filepath)) ( if(Autoloader::debug) Autoloader::StPutFile(("connected" .$filepath)); $flag = FALSE; követelmény_egyszer($fájlútvonal); break ) Autoloader::recursive_autoload($file, $path2, &$flag ) ) zárva Log/Log.html"; $file = fopen($dir, "a"); flock($file, LOCK_EX); fwrite($file, ("║" .$data ."=>" .date(" d.m.Y) H:i:s") ."
║
" .PHP_EOL)); flock($file, LOCK_UN); fclose ($file); ) ) \spl_autoload_register("yourNameSpace\Autoloader::autoload"); )
Ha megnézi a betöltésre érkező osztályok nevét, látni fogja, hogy minden osztály előtt egy előtag szerepel a használatban megadott névtérből. Ezért azt javaslom, hogy a fájlok helyét a névtérhez hasonló könyvtárakban használjuk, ez egy-két iterációra gyorsítja a keresést.

Most az indexünket így írhatjuk fel:
Most az összes használt osztály és interfész automatikusan betöltődik.

A nyelv szóközökkel kapcsolatos dinamikus képességeinek bemutatásához deklaráljunk egy másik osztályt:
teszt.php

Index.php
sayName("teszt"); //vagy megteheti ezt a tesztet\sayName("teszt2"); //vagy így $obj::sayName("teszt"); //vagy elvégezheti ezt a tesztet::sayName("teszt2");

Remélem, hogy cikkem hasznos lesz valakinek.

Egy változó meghatároz egy értéket, de lehet hivatkozás egy másik változóra, és megvan az értéke. Egy algoritmus végrehajtása során egy változó általában sok különböző értéket vesz fel. Egy konstans csak egy értéket tárol. Egy objektum kiszámíthatatlan: szerkezete, tartalma és sok jellemzője van.

A névtér a fejlesztő által létrehozott változók, konstansok, objektumok, függvények és egyéb konstrukciók gyűjteménye, amelyre a névtér nevén keresztül lehet hivatkozni.

Nevek: az adatok és algoritmusok leírásának köre

Az elemek nevei (változók, konstansok, objektumok, függvények és egyéb fejlesztői konstrukciók) soha nem metszik egymást. A PHP bármilyen névegyezést súlyos hibaként értelmez, és olyan esetekben, amikor nem tudja egyértelműen azonosítani a problémát, a fejlesztő olyan kódot kap, amely nem működik megfelelően, vagy egy fehér dobozt kap a böngészőben.

Az összes adat nevének egyedinek kell lennie, mert a tér globális. Az objektumok és függvények nevei szintén nem ismétlődnek, de a globális láthatóság hatóköre megszakad az objektumok és függvények metódustörzseiben. Saját helyi névtere van, és semmi sem akadályozza meg abban, hogy valamit belsőleg ugyanúgy elnevezzen, ahogyan azt kívülről jelölik.

A fenti példa klasszikus, ha nem figyelünk a névtér kulcsszóra: minden olyan, mint mindig. A második alkotásokat tartalmaz. A függvénynevek előtti NameSpaceTwo\ előtag határozza meg, hogy a kód melyik beszúrásból származik.

Ha eltávolítjuk a globális kulcsszót és a műveletet az első függvényből $iExt = 1; lépjen a fenti sorba, akkor sem az első, sem a második függvény nem fog tudni a 100-as változó értékéről.

Névterek: A leírás többféle hatóköre

A bemutatott példa egy megosztott fájlt tartalmaz, amely két beszúrást használ. Minden beszúrásnak ugyanaz az scCheckName() függvénye. Hogy melyiket választja, azt a programozó dönti el, a kód megfelelő helyén, a megfelelő időben releváns szóköz nevével.

Az a tény, hogy ugyanaz a név szerepel a közös kódban (a beszúrások összevonása után), nem okoz hibát azon egyszerű oknál fogva, hogy minden beszúrási fájl saját egyedi névvel van megjelölve.

Az első fájlban minden, ami benne lesz leírva, a NameSpaceOne névhez kapcsolódik. A második fájlban minden leírás a NameSpaceTwo névhez lesz társítva.

Mindkét fájlban megengedett a névmásolás, de mindegyikben az elem nevének (változó, állandó, objektum, függvény) egyedinek kell lennie.

Ebben a példában a névtér nevének megváltoztatása az scCheckName() függvényhívásban megakadályozta, hogy a második névtér $iExt változója megváltozzon. Éppen ezért a példában a „megváltozott” szó külön kiemelve van - a változás valójában nem történt meg. A változó értéke változatlan marad.

Tesztelés és többszörös tervezés

Ezek az egyszerű példák azt mutatják, hogy könnyedén leegyszerűsítheti az összetett projektek fejlesztését, növelheti a hatékonyságot, a termelékenységet és felgyorsíthatja a munkát. Határozottan azonnal megjelentek az első ötletek a névterek használatára:

• szkriptek biztonságos tesztelése - a „munka” terek tesztanalógokkal való helyettesítésével;
• biztonságos tervezés nagy fejlesztői csapatok által – „egyedi” terek biztosításával az elemek leírására.

Valójában a névtér sokkal fontosabb. A PHP nyelv, a névtér és a leírás minden eleme (változó, konstans, objektum...) már régóta lehetővé teszi a fejlesztő számára a szintaxis és a szemantika önálló kezelését.

Nyelvi konstrukciók és a modern programozás általános szabálya: „megértve” – végrehajtva – ellentmondás van – a „fehér képernyőnek” nincs „hatással” egy profi fejlesztőre.

Sok programozó azt sem tudja, hol keresse a PHP hibaüzenetet, ha nincs semmi a böngészőben (üres fehér doboz). Fejlődésének egy bizonyos szakaszában a programozó PHP szintaxisban és szemantikában gondolkodik, automatikusan „működik”, és az eredmény: a saját szintaxisa és saját szemantikája, a megengedett határokon belül.

A fehér képernyő egy professzionális programozó azonnali, egyértelmű reakciója, és a hiba megszűnik. Miért vesztegeti az időt a hibakeresővel és a hibanapló megtekintésével?

Objektumok, tömbök és névterek

Mondhatnánk, hogy a változók, konstansok és függvények a múlté, de az objektumtervezésben használják őket. Jó kód az, amikor az algoritmust egymással kölcsönhatásban lévő objektumok reprezentálják, nem pedig megfelelő konstrukciók sorozata.

Ha objektumtömböket használ, manipulálja a verem ötletét és a tömb utolsó (első) elemét, akkor dinamikát kaphat: az objektumok maguk „döntik el”, hogyan kell működnie a webhely funkcióinak az aktuális helyzettől függően. .

A PHP-ben a névtér egy speciális változó, amelyet saját egyedi neve képvisel, gyakran összetett. A névtér neve kerül felhasználásra a kódban. Ha ez egy karakterlánc, akkor a szkript végrehajtása során az egyik szóközt lecserélheti egy másikra.

Ha a PHP névtérneveket használ változóértékként, akkor ez egy szemantikailag még jobban betöltött szintaxis, még az objektumok tömbjénél is erősebb.

A tárgy olyan szerkezet és tartalom, amelyet egység jellemez. A névtér objektumok, elemek és a köztük lévő kapcsolatok halmaza.

Futó rendszeren nem lehet kísérleteket végezni, de a névtérnek köszönhetően a PHP lehetőséget biztosít egy valós futó rendszer szimulálására egy másik térben a következő célokra:

• további fejlesztés;
• tesztelés;
• karbantartás stb.

Ha elvonatkoztatunk a PHP fejlesztői által javasolt szintaxistól, és a névtereket globális komplex objektumrendszerekként képzeljük el, akkor a lehetőségek horizontja sokszorosára tágul.

A névtér szintaxisa és használata

A PHP csak a névteret fogadja el minden fájl első kódsorában. Minden leírásnak csak ezt kell követnie. A szintaxis csak a név szokásos értelmében vett nevet tartalmazza.

Fontos, hogy a megfelelő szavakat használjuk, amelyek a jelentést közvetítik. Jobb, ha a név hosszú, de tartalmaz valamit, ami világosan megérti, hogy milyen térről beszélünk, mit csinál, mit ír le, mit fogad el vagy mire teremtették.

A szóközök korlátlanul beágyazhatók, de ezt nem szabad túlzásba vinni. A névnek egyértelműnek kell lennie, a beágyazásnak indokoltnak kell lennie, és a szóköznevek sorrendjének logikával kell rendelkeznie.

Használati és névteres alkalmazásokban a PHP lehetővé teszi az összetett kódolást, de amikor csak lehetséges, jobb beérni az egyszerű opcióval.

Az általános szabály a következő: a névtér egy leírás és ez egy fájl, a use a szóköz importálása a use scriptbe, és egy álnév (rövid hivatkozás) hozzárendelése.

Egy egyszerű példa az osztályok (objektumok) automatikus betöltésére

A feladat tartalmaz egy objektumot karakterláncok, oldalelemstílusok (CSS-leírások), dátumobjektum, fájlrendszer-objektum és adatbázis-objektum kezelésére. A megvalósítás lényege, hogy ehhez az öt pozícióhoz egyszerű interfészt kell létrehozni, hogy a szükséges képességeket csak ezen objektumok metódusain keresztül használhassuk.

Nyelvi függvények és konstrukciók közvetlen használata nem megengedett. Ez a feladat PHP osztályú automatikus betöltést használ. A névteret a fájlrendszer egy meghatározott helyén található objektumok gyűjteményének tekintjük. Jellemzően minden objektum jelentésük szerint a fájlrendszerben, mappákban és meghatározott nevű fájlokban található.

A bal oldali kód a szükséges öt objektum létrehozását jelzi, de nem jelzi, hogy pontosan hol találhatók. A jobb oldali kód az autoloader (főszkript) szövegét mutatja, amely az osztályok (objektumok) betöltésekor automatikusan behelyettesíti az objektum helyének és a .php fájlkiterjesztésnek a szükséges elérési útját.

Példa több névtérre

A PhpOffice/PhpWord könyvtár jó példa a több névtér összetett hierarchiájának használatára. Az elemek mappa tartalmazza a *.docx dokumentum (MS Word) készítésekor elérhető elemek szinte teljes körét, a többi mappában az elemekkel, bekezdésekkel és táblázatokkal való munkához szükséges eszközök találhatók.

Valójában azért került a könyvtár a projekt mappába, mert a PhpOffice / PhpWord funkcionalitásteret speciális eszközökkel kellett kiegészíteni, és végül létrehozni egy hasonló termék saját verzióját.

A különböző névterek sok osztályának betöltése

A PHP névtér automatikus betöltése, amikor sok osztály betöltésére van szükség, és a kifejlesztett objektumrendszer hierarchiája meglehetősen bonyolult és nehezen elképzelhető, merev struktúrák létrehozásának szükségességéhez vezet.

A fejlesztő orientációja (aki a terméket a munka folytatására használja) csak a szemantika (a projekt megértése) kontextusában lehetséges, amelyet megfelelő szókombinációk képviselnek, amelyek tükrözik az objektumok valódi jelentését és kapcsolatait.

A könyvtár egyedi projektben való használatának szükségessége a fejlesztői és a PhpOffice / PhpWord szerzői névterek kombinálásának problémájának megoldásához vezet. A legjobb módszer az, ha ezt a terméket (tereit és tárgyait) a saját projektterében helyezi el.

Fontos megjegyezni, hogy ennek a terméknek a névtereit nem lehet módosítani az absztrakt elemei és az osztálybetöltés szintjén. Ez azt jelzi, hogy a PHP névterében előfordulhat, hogy a belső névterek használata nem elég absztrakt és univerzális.

Fájlrendszer és a szóközök lokalizálása

A névterek lényegében a kívánt objektum elérési útjának „rajzai” a fájlrendszerben. A fájlnevek objektumnévként való használata természetes és ismerős. A mappanevek névtér-elnevezésként való használata objektív.

Az információ „fából készült” rendszerezése meglehetősen körülményes a használata és bonyolítja a fejlesztést, de az objektumrendszerek természetes reprezentációja.

A probléma az, hogy a fejlesztési szakaszt egy speciális kódszerkesztő képviseli, amely a mappák látható megjelenítését és egy adott mappa tartalmát is kombinálja, de még nincs olyan szerkesztő, amely végpontok közötti mozgást biztosítana az objektumokon és azon keresztül. mappákat.

Az absztrakció és az egyetemesség problémája

A fejlesztő tudata és célja a valóságban elfogadta:

• absztrakciót és az információ valós szemantikája szerinti manipulálásának képességét biztosítja;
• A névterek tükrözik a szkriptek, objektumok helyzetét és részben a projekt jelentését a fájlrendszerben

Valójában az OOP absztrakciót objektumnevekhez (fájlokhoz) kapcsolva, és a fájlrendszerre (mappákra) megfelelő névtérképzéssel (útvonalak + nevek) lefedve szabályozhatja a névterek képződését a szkript végrehajtása során.

A programozás már korábban is erőteljes fejlesztési dinamikát kapott, de ha a fejlesztési szakasz folyamatát és munkaterhét egy szövegszerkesztőről (amelyben a szkriptek jönnek létre és a mappafákba helyezik) átvisszük egy olyan kód generálására, lehetővé teszi a fejlesztést és a fájlrendszer megfelelő helyére helyezését - a programozás új magasságokba emelkedik.