Varför bry sig om automatisk laddning i WordPress, del 2
I det förra inlägget tog jag upp några punkter om varför jag tror att include_once, require_once och andra liknande påståenden resulterar i dåliga utvecklingsmetoder (åtminstone när det kommer till arbetet vi gör med våra WordPress-projekt ).
Om du inte har läst den, ingen stor sak. Kontentan av inlägget är att dessa uttalanden gör:
- svårare att felsöka,
- spårningskod svårare att göra.
I slutändan är de saker vi kan undvika. Jag avslutade inlägget med följande:
Detta lämnar fortfarande frågan om varför autoloading (eller någon inkludering av tredjepartsfiler) överhuvudtaget behövs.
Och även om jag skulle älska att täcka alla detaljer i det här inlägget, kommer det att ta detta och ytterligare ett inlägg som det är viktigt att förstå några grundläggande ämnen om språk, tolkar och kompilatorer innan du går för långt fram.
Automatisk laddning i WordPress: Typer av språk
När det gäller programmeringsspråk kan de delas upp i två olika typer av språk:
- statiskt typad
- dynamiskt typad
De är också lätta att upptäcka.
Statiskt skrivna språk
Ett statiskt skrivet språk betyder att när du deklarerar en variabel, som en sträng, ett heltal eller ett flyttal, behåller den den typen under hela sin livstid.
Detta betyder inte att det inte kan ändras eller analyseras till en annan typ, men tanken är att du deklarerar dess typ och det är så det fungerar.
Det anges vanligtvis som en viss typ när det deklareras, som string eller int, och det ses oftast på kompilerade språk.
Dynamiskt typade språk
Dynamiskt typade språk, å andra sidan, har variabler som är mer flytande, i brist på en bättre term, till sin natur.
Det vill säga, du kan initialt deklarera det som en sträng och sedan jämföra det med ett heltal och senare använda det som en sträng igen.
Tolken eller kompilatorn (beroende på vilket språk du använder) kommer att göra det bästa den kan för att sluta sig till vad du försöker göra baserat på sammanhanget för vad du gör i din kod, men det är inte alltid rätt.
Det kan leda till konstiga biverkningar och buggar.
JavaScript är så här. För att se ett exempel, öppna din webbläsares konsol och skriv in något liknande det du ser i följande skärmdump (och var uppmärksam på resultatet):
Lägg märke till att när vi använder ett vanligt dubbellika-tecken, tvingar tolken strängen till den booleska typen även om den sanna strängen inte är sann.
Det andra fallet är korrekt (och det är därför trippellika nästan alltid bör användas).
Dessutom, hur något kan fungera på ett språk är inte hur det kan fungera på ett annat språk.
Summan av kardemumman är att förvänta dig inte att dina språk gör samma sak bara för att de kan stödja dynamisk skrivning.
Vad har detta med autoladdning att göra?
Okej, så vi har pratat lite om primitiver och allt det där är bra, men det gör inte så mycket när man pratar om klasser, objekt, instansiering, autoloading och så vidare, eller hur?
Syftet med att ta upp ovan nämnda ämnen är att visa vilken roll tolkar och kompilatorer spelar när de arbetar med kod i dynamiska språk.
Och detta är viktigt eftersom PHP är ett dynamiskt språk.
Vid det här laget skulle jag ursprungligen börja titta på exempel på PHP-kod, namnutrymmen, autoloading, include – satser och allt det där, men jag försöker hålla mina artiklar i en viss längd och detta började sträcka sig lite längre än jag ville .
Så den ultimata take away från detta inlägg, om jag måste sammanfatta det, är detta:
Dynamiskt typade språk, som PHP, ges inte lyxen av kompilerade språk där allt kompileras till en enda binär. Vi måste berätta för programmet, på något sätt, var beroenden finns inom ramen för det större programmet.
Och det är vad jag ska ta upp i nästa inlägg.