Tie­to­tyyp­pien sekamelskaa WordPres­sis­sä

PHP ei pakota pitämään kiinni tietotyypeistä. Aikaisemmin PHP:ssä ei edes ollut mahdollista merkitä tyyppejä, mutta tyyppivihjeet tulivat mukaan PHP:n vitosversiossa vuonna 2004. Viimeisten kahden vuosikymmenen aikana PHP:n tyyppijärjestelmä on kehittynyt valtavasti ja alkaa jo olla varsin hyvällä tolalla — joskaan siitä ei saada täyttä hyötyä irti, koska suuri osa olemassa olevasta PHP-koodista käsittelee tyyppejä miten sattuu. Erityisen pahasti tähän PHP-koodin helmasyntiin syyllistyy maailman suosituin PHP-sovellus, WordPress.

PHP-standardien suhde tietotyyppeihin

PHP:lle on luotu oma ohjelmointistandardistonsa, PSR, joka määrittelee melko tarkasti sen, miten PHP-koodia tulisi kirjoittaa. PSR ei kuitenkaan ota toistaiseksi kantaa siihen, miten tietotyyppien kanssa tulisi toimia. WordPressille tällä ei toki olisi ollutkaan mitään väliä, koska WordPress määrittelee oman PHP-ohjelmointistandardinsa, joka ei ole millään tavalla linjassa PSR:n kanssa. Minusta tässä koko asetelmassa on kolme ongelmaa:

1. PSR ei ota kantaa tietotyyppien merkitsemiseen tai PHP:n ajamiseen strict_types-tilassa. Tämän pitäisi ehdottomasti olla mukana PSR:ssä.
2. Maailman suosituin PHP-sovellus ei noudata yleisiä PHP:n ohjelmointikäytäntöjä (joita käytännössä koko muu PHP-ekosysteemi noudattaa), vaan määrittelee omat ohjelmointikäytäntönsä. WP:n ohjelmointikäytännöissä lisäksi mainitaan, että käytäntöjä voi noudattaa myös ilman, että koodi tyylillisesti vastaisi WP:n määritelmää. Eli käytännössä WP:n kanssa toimittaessa koodi voi olla tyylillisesti millaista vain, mutta todennäköisesti ei ainakaan sellaista, joka vastaisi PSR:n määrittelemää tyyliä.
3. Myöskään WP:n ohjelmointikäytännöt eivät ota mitenkään kantaa tietotyyppien merkitsemiseen muuten kuin tyylillisesti. Vaikuttaisi siltä, että tilanne tulee tällaisena myös pysymään hyvin pitkään, koska WP:n dokumentaatiossa on tietotyyppejä koskien seuraavanlainen varoitus: ”Adding type declarations to existing WordPress Core functions should be done with extreme care.”

PHP tarjoaa siis oikeastaan aika hyvän tyyppijärjestelmän, mutta PHP-ekosysteemi ei sitä varsinaisesti halua toistaiseksi hyödyntää. Todennäköisesti pelkona on se, että PHP:n siirtyessä entistä enemmän tiukasti tyypitetyn kielen suuntaan karkaisi suurin osa PHP:n kohdeyleisöstä jonkin muun kielen pariin.

Tietotyyppiongelmat WordPressin kanssa

WordPressin kanssa toimittaessa suurimmat tietotyyppeihin liittyvät ongelmat ovat funktioiden palautusarvoissa. Suuri osa WordPressin funktioista palauttaa arvoja vaihtelevilla tietotyypeillä tai tyypillä, jota ei välttämättä ihan heti olisi osannut odottaa. Tässä muutama esimerkki:

• get_block_asset_url-funktio palauttaa joko merkkijonon tai totuusarvon. Koska PHP suorittaa tyyppimuunnoksia hiukan joka välissä, voi tämä teoriassa johtaa mielenkiintoiseen tilanteeseen. Esimerkiksi tyhjä merkkijono muuntuu totuusarvona falseksi, samoin merkkijono, jonka sisältönä on pelkästään 0. Kannattaa siis pitää huoli siitä, että tämän funktion palautusarvon vertailut esimerkiksi if-lausekkeissa tehdään käyttäen ===-operaattoria.

• get_post_type_labels-funktio palauttaa olion, joka koostetaan yhdistämällä kaksi taulukkoa array_merge-funktiolla ja muuntamalla tulos PHP:n sisäänrakennetun stdClass-luokan yleisolioksi — eli funktion nimen perusteella tulisi monta asiaa, mutta tuleekin yksi olio, jonka muoto pitää itse selvittää. Tämä on ihan vain outoa.

Tällaiset tietotyyppeihin liittyvät erikoisuudet tekevät WP:lle ohjelmoimisesta aika hähmäistä ja hankalaa. WP:n kanssa ei voi luottaa intuitioon, vaan API-dokumentaatio on pakko pitää käden ulottuvilla jatkuvasti. Onneksi nykyaikaiset editorit tukevat LSP-protokollaa, jonka kautta apua on hyvin saatavilla suoraan koodia editoitaessa.

Miten tietotyyppien kanssa kannattaa toimia WP:ssä?

Vaikka WP:n omassa koodissa ei hyödynnetäkään tietotyyppejä, se ei ole syy olla käyttämättä tietotyyppejä räätälöidyissä toteutuksissa. Suuri osa räätälöidystä koodista kannattaa kirjoittaa niin, että PHP:ta käsitellään tiukasti tyypitetyn kielen tapaan. Hyvä idea on myös hyödyntää PHP:n strict_types-moodia, joka asettaa PHP:n tiukasti tyypitetyksi yksittäisen tiedoston kohdalla.

Erinomainen tapa tyyppijärjestelmän hyödyntämiseen on tehdä luokkapohjaisia toteutuksia. Luokat ovat tyyppejä, joten niitä voi suoraan käyttää arvojen validoinnissa. Juuri tällainen toteutus auttaisi korjaamaan muun muassa yllä mainitun get_post_type_labels-funktion toiminnan: funktio voisi palauttaa arvon, joka kuvastaisi kunnolla sitä, että kyse on jonkinlaisesta joukosta arvoja (toki ihan normaali arraykin olisi nykytilannetta parempi).

On tärkeää muistaa, että tyyppijärjestelmän tulee kunnolla pystyä myös kuvaamaan niitä tapauksia, joissa arvoa ei pystytä muodostamaan. WP:n toteutuksille on hyvin tyypillistä käyttää näissä tapauksissa false-totuusarvoa. Merkittävästi parempi ratkaisu olisi käyttää null-arvoa, sillä PHP:ssä on nykyään omat operaattorinsa null-arvojen käsittelyä helpottamaan (?? ja ??=). Vielä parempi ratkaisu toki olisi toteuttaa tietotyyppi, joka voisi suoraan esittää myös puuttuvat arvot (ns. option-tyyppi).

Mikäli tarkoituksena on rakentaa kertaluokkaa isompi toteutus, saattaa olla järkevää pyrkiä käärimään suuri osa WP:n API:stä oman, luokkapohjaisen toteutuksen sisään. Tällöin mikään ei estä rakentamasta sellaista tyyppikokonaisuutta, joka parhaalla mahdollisella tavalla tukee toteutuksen sisäistä maailmaa. Se on myös hyvä tapa varmistaa, että sovelluksen sisäinen rajapinta pysyy yhtenäisenä ja loogisena.