✅ WEB ja WordPressi uudised, teemad, pistikprogrammid. Siin jagame näpunäiteid ja parimaid veebisaidi lahendusi.

Miks WordPressis automaatse laadimisega vaeva näha, 2. osa

17

Eelmises postituses käsitlesin mõnda punkti, miks ma arvan, et include_once, request_once ja muud sarnased väited põhjustavad kehva arenduspraktika (vähemalt mis puudutab tööd, mida me oma WordPressi projektidega teeme). ).

Kui te pole seda lugenud, pole sellest suurt midagi. Postituse põhiolemus on see, et need avaldused näitavad:

  1. silumine keerulisem,
  2. jälgimiskoodi on raskem teha.

Lõppkokkuvõttes on need asjad, mida saame vältida. Postituse lõpetasin järgmisega:

See jätab endiselt küsimuse, miks on automaatset laadimist (või mis tahes kolmanda osapoole failide kaasamist) üldse vaja.

Ja kuigi mulle meeldiks selles postituses käsitleda kõiki üksikasju, on see ja veel üks postitus oluline, et mõista mõningaid põhiteemasid keelte, tõlkide ja kompilaatorite kohta, enne kui hakkan liiga kaugele edasi minema.

Automaatne laadimine WordPressis: keelte tüübid

Kui rääkida programmeerimiskeeltest, võib need jagada kahte erinevat tüüpi keeltesse:

  1. staatiliselt trükitud
  2. dünaamiliselt trükitud

Neid on ka lihtne märgata.

Staatiliselt trükitud keeled

Staatiliselt tipitud keel tähendab, et kui deklareerite muutuja, näiteks stringi, täisarvu või ujukomaarvu, säilitab see selle tüübi kogu selle eluea jooksul.

See ei tähenda, et seda ei saaks muuta või teiseks tüübiks sõeluda, kuid mõte on selles, et deklareerite selle tüübi ja nii seda kasutatakse.

Tavaliselt määratakse see deklareerimisel teatud tüübina, näiteks string või int, ja seda nähakse kõige sagedamini kompileeritud keeltes.

Dünaamiliselt sisestatud keeled

Dünaamiliselt trükitud keeltes on seevastu muutujad, mis on parema termini puudumisel olemuselt sujuvamad.

See tähendab, et võite selle alguses deklareerida stringina, seejärel võrrelda seda täisarvuga ja hiljem uuesti stringina kasutada .

Tõlk või kompilaator (olenevalt kasutatavast keelest) teeb kõik endast oleneva, et järeldada, mida proovite teha, lähtudes sellest, mida oma koodis teete, kuid see ei ole alati õige.

See võib põhjustada kummalisi kõrvalmõjusid ja vigu.

JavaScript on selline. Näite nägemiseks avage oma brauseri konsool ja sisestage midagi sellist, mida näete järgmisel ekraanipildil (ja pöörake tähelepanu tulemusele):

Pange tähele, et kui kasutame standardset topeltvõrdusmärki, sunnib tõlk stringi Boole’i ​​tüübiks, kuigi tegelik string ei ole tõene.

Teine juhtum on täpne (ja seepärast tuleks peaaegu alati kasutada kolmekordset võrdsust).

Lisaks sellele, kuidas miski võib ühes keeles toimida, ei pruugi toimida teises keeles.

Põhimõte on see, et ärge oodake, et teie keeled teeksid sama lihtsalt sellepärast, et need võivad toetada dünaamilist tippimist.

Mis on sellel pistmist automaatse laadimisega?

Olgu, nii et me oleme rääkinud natuke primitiividest ja kõik see on hea, kuid see ei tee palju, kui räägime klassidest, objektidest, instantseerimisest, automaatsest laadimisest jne.

Eelnimetatud teemade väljatoomise eesmärk on näidata, millist rolli mängivad tõlgendajad ja kompilaatorid dünaamilistes keeltes koodiga töötamisel.

Ja see on oluline, kuna PHP on dünaamiline keel.

Siinkohal kavatsesin algselt hakata uurima PHP-koodi näidist, nimeruume, automaatset laadimist, kaasamise avaldusi ja kõike seda, kuid püüan hoida oma artikleid teatud pikkusega ja see hakkas venima veidi kaugemale, kui ma tahtsin. .

Nii et selle postituse ülim äravõtt, kui peaksin selle kokku võtma, on järgmine:

Dünaamiliselt trükitud keeltele, nagu PHP-le, ei anta luksust kompileeritud keeltele, kus kõik on kompileeritud üheks kahendfailiks. Peame programmile mingil moel ütlema, kus suurema programmi kontekstis on sõltuvused olemas.

Ja seda püüan järgmises postituses käsitleda.

See veebisait kasutab teie kasutuskogemuse parandamiseks küpsiseid. Eeldame, et olete sellega rahul, kuid saate soovi korral loobuda. Nõustu Loe rohkem