pronto.ee

Tomorrow will be cancelled due to lack of interest

PHP 8.0: Muudatus funktsioonis strrpos()

PHP

Nüüd kus PHP 7.x-i enam parketikõlbulikuks ei peeta ilmneb, et mitte kõik rakendused ei taha uuemate PHP versioonidega toimida. Mitte alati ei ole nende põhjus üheselt selge ning töö käigus ilmnevad siin ja seal pooldokumenteeritud muudatused mis võivad lohakale arendajale kaika valusal kombel kordaratesse torgata. Üheks selliseks funktsiooniks on strrpos().

Selleks, et asja olemusest aru saada tuleb vaadata kõigepealt funktsiooni signatuuri ja pöördumisväärtuseid. Php.net ütleb selles kohta nii:

strrpos(string $haystack, string $needle, int $offset = 0): int|false

Returns the position where the needle exists relative to the beginning of the haystack string (independent of search direction or offset).

Returns false if the needle was not found.

Enne PHP 8.0-t töötas see funktsioon nõnda, et kui $offset läks string piiridest välja (tavaliselt oli selle põhjuseks tühi $haystack) oli pöördumisväärtuseks false. Alates PHP 8.0-st on tulemuseks hoopis:

Fatal error:  Uncaught ValueError: strrpos(): Argument #3 ($offset) must be contained in argument #1 ($haystack)

Ehk siis tulemuseks on kriitiline viga ning koodi edasi töötlemine lõpetatakse. Ühest küljest on see halb, sest dokumentatsioon seda situatsioon ei kata. Teisest küljest on see mõistetav, sest strrpos() on lõppeks ikkagi funktsioon ning hea tava näeb PHP-s ette, et küllalt ressursimahukaid funktsioone ei kasutata tuvastamaks kas andmeid on võimalik töödelda või mitte. Igal juhul oleks korrektne lahendus kontrollida if lausega ega string juhtumisi pole tühi. Alternatiivse variandina võib try / catch-iga püüda kinni \ValueError ja jätkata nii nagu algne kood ette nägi. See viimane lahendus läheb loomulikult vastuolla heade tavadega, kuid teinekord on oluline lihtsalt kood käima saada.

Siinkohas oleks paslik märkida, et \ValueError on uuendus mis toodi sisse PHP 8.0-s. Ehk siis sellepüüdmine ei toimi varasemate PHP-dega. Kui kood peab olema ka tagurpidi ühilduv peaks kasutama kas \Exception-it või klassi polyfillimist:

if (!class_exists('\ValueError')) {
    class ValueError extends \Error {
    }    
}

Ahjaa, märkuseks niipalju veel, et kuigi algne teemapüstitus puudutas ühte konkreetset funktsiooni mõjutab see muudatus veel teisigi, näiteks strpos(), range(), array_rand() ja võib-olla midagi veel on samuti selles muudatusest mõjutatud.

PHP 8.3: json_validate()

Kuigi PHP 8.3 ei ilmu just homme (hetkel on see planeeritud selle aasta 23. novembriks) on aeg hakata kaema sellega kaasnevaid uuendusi. Esimeseks neist saab olema uus funktsioon json_validate().

PHP

JSON (JavaScript Object Notation) on avatud andmestandard mida on juba aastaid kasutatud andmete vahetamiseks ning salvestamiseks, mis on õhuke ning minimaalselt ressurssi nõudev ja ühes sellega päris paljudes kontekstides praeguseks asendanud XML-i. Praeguseks on nii, et kui mingid asjad peavad veebis omavahel andmeid vahetama, siis tavaliselt kasutavad nad selleks JSON formaati. Asjale muidugi aitab kaasa ka nüanss, et JSON on enam-vähem inimloetav, andmete kontrollimiseks ei ole seetõttu vaja eraldi tööriistu.

Samas on PHP-s JSON-ga seotud üks väike kuid tülikas probleem: nimelt selleks, et kontrollida andmeformaadi õigsust pidi varem andmed json_decode() abil objektiks konverteerima. Kui andmemahud olid piisavalt suured, siis tõstis see andmevahetuskihi jaoks nõudeid protsessorile või töötlemisajale, mis näiteks AWS-i puhul kippus kiiresti reaalseteks kuludeks muutuma. Sestap siis json_validate(), mille eesmärk on vaid andmeid kontrollida.

Funktsiooni signatuur näeb välja selline:

/**  
 * Validates a given string to be valid JSON.
 * 
 * @param string $json String to validate  
 * @param int $depth Set the maximum depth. Must be greater than zero.  
 * @param int $flags Bitmask of flags.  
 * @return bool True if $json contains a valid JSON string, false otherwise.  
 */  
function json_validate(string $json, int $depth = 512, int $flags = 0): bool {  
}

Kes tahab sellest funtksioonist rohkem teada saada vaadaku siia ja kui kedagi beaks huvitama bitmaski väärtused, siis selle info leiab siit.

Märkuseks veel niipalju, et seda funktsioon on võimalik polyfillida, ehk siis koodi on võimalik teha vanemate PHP versioonidega ühilduvaks kasutade järgmist meetodit:

if (!function_exists('json_validate')) {  
  function json_validate(string $json, int $depth = 512, int $flags = 0): bool {  
    if ($flags !== 0 && $flags !== \JSON_INVALID_UTF8_IGNORE) {  
      throw new \ValueError('json_validate(): Argument #3 ($flags) must be a valid flag (allowed flags: JSON_INVALID_UTF8_IGNORE)');  
    }  

    if ($depth <= 0 ) {  
      throw new \ValueError('json_validate(): Argument #2 ($depth) must be greater than 0');  
    }  

    \json_decode($json, null, $depth, $flags);  

    return \json_last_error() === \JSON_ERROR_NONE;  
  }  
}

See lahendus on hetkel PHP 8.0 ühilduv ning kui \ValueError asendada näiteks \Exception-ga, siis töötab see isegi PHP 7.3-ga. Sestap võib selle funktsioni juba praegu oma koodi lisada.

Ukraina: Mis saab edasi?

Iga konflikt saab lõpuks otsa: mõned varem, mõned hiljem; ajalugu tunneb nii kuuepäevaseid sõdu kui saja-aastaseid. Senikaua kuniks tint pole lepingul kuivanud on väga raske anda hinnangu sündmuste käigule ja Vene vallutussõda ei ole selle koha pealt mingi erand.

Üks asi mis selle konflikti puhul erandlik on, on sellega teotud tohutu hulk soovmõtlemist, fakidel mittepõhinevat eeldamist mida üks või teine osapool võib mõelda ning toetumine infole mis parimal juhul on propagandahõnguline ning halvimal juhul lihtsalt infooperatsioonide osa. Sõjas ja armastuses on teatavasti kõik lubatud mis praktikas tähendab seda, et ükskõik kui ebatõenäoline üks või teine stsenaarium ka poleks on see ikkagi laual kui seda just mingil põhjusel ümbertõukamatult välistada ei saa.

Näiteks Ukaina anastamine kolme päevaga on selline, mida saab.

Numbrid

Enne hinnangute andmisega edasi liikuda tuleks vaadata üle numbrid.

Praeguseks on venelased suutnud Ukraina vastu saata umbes 500000 meest, kellest umbes viiendik on naasnud mustas kilekotis ja teine viiendik on lõplikult võitlusvõimetu. Need kaks viiendiku moodustavad laias laastus kogu algse konflikti suunatud kontingendi. Märkuseks niipalju, et tegemist on Ukraina päritolu arvudega kuid liitlased on seisukohal, et need on hinnangute andmiseks piisavalt tõelähedased.

Pärast seda kui Moskva võimukandjad said aru oma algsete eelduste (Ukraina annab kohe alla) ekslikusest ning lähtudes üheksa kuu jooksul saadud valusatest kogemustest on sealsetest allikatest lekkinud uus hinnang: sõja võitmiseks on neil vaja 5 miljonit meest. See tähendaks seda, et Venemaa saadaks rindele viiendiku kõikidest võitlusvõimelistest meeskodanikest. Kui asi konteksti panna siis Eesti puhul oleks võrreldav number 50000 meest. See tähendaks seda, et neil oleks paugupealt viis miljonit inimeste keda tuleb toita, katta, relvastada, transportida ja ravida ning kelle töökäed on majandusest selleks perioodiks eemal. Arvestades sellega, et venelastel on kukil sanktsioonid ning olemasolev aur on juba suuresti vile peale ära kulutautd on äärmiselt ebatõenäoline, et nad suudaks selle numbri kokku saada.

Üks number on meediast veel läbi jooksnud: 100000 surnut on see number mil agressorriigi kodanikud hakkavad tajuma sõja hinda ning küsima selle põhjendatust. Ukrainlaste anmetel peaks see hulk täis saama veel selle aasta sees. Arvestades sellega, et juba mobiliseeritud pool miljonit sõjameest pole olukorda oluliselt muutunud (tõsi, mitte kõik pole veel rindele jõudnud) pole alust oodata, et täiendav mobilisatsioonilaine idas avasüli vastu võetaks.

Üks märkus veel — ründaja on kulutanud ära lõviosa oma kvaliteetsemast moonast mis tähendab seda, et mängu on tulnud 30-40 aastat vanad reservid. Lõhkeaine muutub seistes aga järjest ebastabiilsemaks ning see võib omakorda olla põhjuseks miks siin ja seal relvalaod ilma ühegi mõjuva põhjuseta vastu taevast lendavad. Ukrainlastele see muidugi sobib.

Tuumanupp

Iga kord kui Ukrainas toimub jutuks tuleb mainitakse vääramatult ka Venemaa kui tuumariigi staatust ning loomulikult kasutab Moskva seda hirmu Ukraina ja Ukraina liitlaste heidutamiseks. Praktikas on tuumaoht tegelikult minimaalne.

Tuumarelvad jagunevad suures plaanis kaheks: strateegilised ja taktikalised.

Strateegilised tuumarelvad on suure purustusjõuga ja need on relvad mis lastaks käiku siis kui kaotada pole enam midagi. Tavaliselt on need tänapäeval kas siis maalt või merelt (peamiselt allveelaevadelt) välja tulistatavate mandritevahelised raketid ja paarist sellisest piisab, et Tallinn rusuhunnikuks muuta + loomulikult radioaktiivne reostus. Need relvad tuleks mängu siis kui Ukraina väed Punasele väljakule jõuavad. Seda võimalust ei ole mõtet praegusel hetkel isegi kaaluda.

Taktikalised tuumarelvad on suhteliselt väikese purustusjõuga ja võrreldavad ülemise otsa tavaarsenaliga. Need on mõeldud suuresti heidutamiseks, sest nende praktiline väärtus on madal. Nagu strateegilistegi relvade puhul kaasneb lisaks purustustele radiaktsioon mis tähendab seda, et selle kasutamine oma vägede / territooriumi vahetus läheduses on problemaatiline.

Teine aspekt on taktikaliste tuumarelvade puhul see, et ukrainlased on muutunud üliosavaks vastase lennukite ja rakettide likvideerimises ning sedavõrd kuidas liitlaste õhutõrjetehnika leiab tee sinna, paraneb olukord veelgi.

Kolmandast küljest on venelaste tuumatehnika aastakümneid ladudes tolmu kogunud ja nende töökindlus on parimal juhul küsitav.

Ning neljas, tõenäoliselt olulisim tahk on see, et pärast trateegiliste pommitajate hävitamist lennuväljal, mis asus Ukraina piirist kaugemal kui Moskva ei ole alust uskuda nagu Ukraina ei korraldaks vasturünnakut näiteks Kremli pihta.

Loomulikult ei saa unustada ka seda, et Ukraina on siiki tuumariik, nende territooriumil asub hulk tuumajaamasi mida nad haldavad ja arendavad ise. Praktikas on täiesti võimalik, et neil siiski on tuurmarelv või vähemalt võimekus see väga lühikese aja jooksul luua. Kas venelased on valmis selle võimalusega riskima?

Venemaa alistub

Venemaa ajalugu on täis vallutussõdu. Mida jäetakse tihtipeale mainimata on see, et vallutusõdadest taandumise ajalugu on neil peaaegu sama pikk: Talvesõda, Eesti Vabadussõda, analoogsed avantüürid Lätis ja Leedus, Jaapani sõda, sõda Türgiga on vaid mõned näited. Kui saab selgeks, et algsed hinnangud ei vastanud tõele ning selgub, et ka toores jõud ei aita on venelastel kombeks oma koju tagasi ronida, viisakalt andeks paluda ja reparatsioone maksta; eriti siis kui rahvusvaheline üldus selgelt nende vastu on.

Võimalik, et läbirääkimised sellel teemal juba käivad — Marconi poolt lauale pandud vihjed, et Venemaa otsib julgeolekugarantiisi, viitavad just sellele. Ka on viimastel nädalatel oluliselt muutunud agressori retoorika. Osaliselt on see muidugi tingitud Hersonist taandmisest, kuid lisaks tuntub, et Moskva on aru saanud selle konflikti võimatusest ja otsib väljapääsu. Hetkel on veel võimalik taanduda niivõrd-kuivõrd tingimusi esitades kuid sedavõrd kuidas surve rinnetel kasvab tõuseb taandumise hind.

See kas Venemaa alistub ei ole enam kas? vaid millal? küsimus.

Mustale merele

Kui Venemaa ei alistu, siis varem või hiljem murrab Ukraina läbi Aasovi merele mida Venemaa peab oma sisemereks. Hetkel on selleks kaks liini: Dnepri jõgi või Melitopol. Mõlema puhul on tulemus sama: Krimm kaotab varustusliini maismaa kaudu, venelased peavad hakkama sõdima kahel rindel ning lisaks on praktiliselt kogu poolsaar laskeulatuses. Krimmis elab ühtekokku kaks ja pool miljonit elaniku mida ei ole ka parima tahtmise juures võimalik sõjaolukorras Kertši silla ja praamidega varustada.

Vaadates venelaste Musta mere laevastiku liikumist on päris selge, et nad on sellest teemast akuutselt teadlikud. Suur hulk laevu on Aasovi merelt minema viidud ning ka Krimmi sadamad hakkavad vaikselt tühjenema. Poolsaarelt veetakse minema kõiki ja kõike mida ukrainlastele jätta ei soovita.

Krimm on loomulikult venelaste jaoks vägagi mõru mari, sest erinevalt muudest territooriumitest on see olnud Venemaa kontrolli all juba kaheksa aastat ning seda peetakse “omaks”. Samas on ainus maismaaühendus sinna läbi Ukraina ning lisaks on suur osa veevarustusest seotud mandriga. Ja seda on praeguses olukorras peaaegu võimatu kaitsta.

“Rahvavabariigid”

Erinevalt Krimmist on venelaste käes kaks territooriumi mida nad saavad kaitsta kui nad otsustavad mitte alistuda ja mida nad püüavad kaitsta. Nendeks on Luhanski ja Donetski “rahvavabariigid” — seda eriti siis kui Krimm Ukraina kätte liigub, kuna see vabastab oluliselt vahendeid. Sealtkandist pärinevad ka viimaste aegade ainsad “edulood” — sadakond meetrit siit ja sealt hõivatud maad.

See on osaliselt põhjuseks miks Ukraina pole selles suunas erilisi jõupingutusi teinud: ühest küljest on varustusliinid sinna suhteliselt lühikesed, teisest küljest võib seal eeldada venelaste meeleheitliku vastupana. See poleks ka ime kuna kogu “sõjaline operatsioon” algas ju nende abistamise egiidi all. Ning lõpuks ei saa unustada ka seda, et taaskord kaob maismaaühendus Krimmiga.

Kas venelastel on üldse lootust?

Sedavõrd kuidas konflikt edeneb ja Ukrainal edulugusi ette on näidata, on liitlased valmis sajaseid luftitama ning sinna üha moodsamaid ja võimsamaid relvi saatma. Loomulikult pole see pelgalt abikäe ulatamine, osa varustust on laenatud ning kuna paljud vahendid pole varem reaalselt lahingutegevust näinud võib seda nimetada nende jaoks tuleristseteks. Ometigi kui aasta jooksul uusi tulemusi ette pole näidata hakkab sponsorite tuhin ühelt maalt raugema ning vahepeal kätte võidetud või käest antud piirid kivistuma.

Tõenäosus, et venelastel õnnestub nii pikalt vastu pidada on looumlikult madal kuid ajalugu on näidanud, et traditsiooniline loogika sealmaal ei päde. Sestap jääb üle vaid loota, et nii ukrainlaste tahe kui liitlaste abi on vankumatud ning parem varustus ning kõrgem moraal hoolitsevad selle eest, et surve karges talvehämaruses ei raugeks.

Mäng: “Return to Monkey Island”

“The Secret of Monkey Island” (1990) ja selle jätk “Monkey Island 2: LeChuck’s Revenge” (1991) olid mängud mis silmapilk kolm meest kelleks olid Ron Gilbert, Dave Grossman ja Tim Schafer mängumaailma tippude hulka lennutasid. Nende peategelaseks on asjaarmastajast piraat nimega Guybrush Threepwood, kes üritab muude mereröövlite hulgas endale nime teha ja samal aja Ahvisaare saladuse jälile saada. Loomulikult on tema tee sinna okkaline ning sillutatud vähemal või suuremal määral koomiliste vahejuhtumitega. Erinevalt muudest analoogsetest mängudest kumasid lõbusa pealispinna alt välja mitmed tunduvalt tõsisemad teemad ning sestap lõppeski teine mäng sellise nukravõitu alatooniga.

Nüüd kus peaaegu kolmandik sajandist on selja taha jäänud ning kuhu mahub lisaks neli teiste tegijate poolt valmis sepistatud osa ja paar uusversiooni, otsustasid kaks algset autorit, Ron Gilbert ja Dave Grossman, et aeg on Guybrush tolmust puhtaks kloppida ja vanale ametipostile tagasi kutsuda. Sest vaatamata peategelaste pungutusele pole endiselt selge mis lugu selle Ahvisaare saladusega täpselt on. Nii ilmuski selle aasta 19. septembril sarja seitsmes osa mis kannab nime “Return to Monkey Island”.

Aga. Selgub, et tegemist on siiski kolmanda osaga — mängumeistrid otsustasid vahepeal ilmunud jägesi lihtsalt ignoreerida ja nõnda võib julgelt öelda, et tegelikult on tegemist siiski sarja kolmanda osaga. Seda ühest küljest selle tõttu, et see hakkab pihta täpselt sealt kust teine mäng pooleli jäi ja teisest küljest selle tõttu, et see on esimene mäng pärast teist osa mis kannab endas edasi algsete osade vaimu.

Mängu läbivaks teemaks on lugu mida juba halliseguste juustega Guybrush oma pojale (kelle nimi on — tegelikult ka — Boybrush) jutustab ja räägib kuidas ta lõpuks siiski Ahvisaare saladuse jälile sai. Loomulikult ei puudu selle juurest ka LeChuck, kellele on sama kinnisidee mis peategelasel, Elaine, Voodoodaam ja paljud teised varasematest osadest tuttavad asjapulgad. Kohe alguses selgub, et aeg on edasi läinud ja vanade piraadipealikute asemel laiutavad Scumm baaris noored idupiraatidest (ehk võib neid nii nimetada) tõusikud, kes vana kooli Guybrushile juba sissejuhatavalt viltu vaatavad.

Uue mängu jaoks on Ron Gilbert kirjutanud valmis uue mootori mis kannab nime Dinky. Osaliselt tänu sellele on mängu visuaal mõnevõrra teistsugune kui varasematel osadel, kuid arvestadaes sellega, et tehnilised võimalused on arenenud on see pigem hea. Siinkohas oleks paslik märkida ka seda, et helipildi eest hoolitseb algsete osade muusika autor Michael Land ning tema loodud viisid on lihtsalt maagilised.

Lisaks tehnilistele lahendustele on mängus hulk väikeseid kuid olulisi detaile. Näiteks ei ole ükski mõistatus selline kus tuleb lihtsalt huupi asju kokku panna ja näha mis juhtub. Kõik asjad mängus on loogilised ning täpselt nõnda keerulised, et hallid ajurakud täies mahus koormatud saaks. Kelle jaoks seiklusmängudes nuputamine pole mokkamööda, see võib valida omale lihtsama versiooni kus mõistatusi on vähem ja allesjäänud mõistatused on kergemini hoomatavad. Mängu on sisse ehitatud ka vihjesüsteem ning kui tundub, et enda mõistus enam peale ei hakka võib sealt abi küsida. Esimesed vastused on väga ebamäärased ning kui hammas ikka peale ei hakka, siis järjest konkreetsemad ning selgemad.

Ühe meeldivad detailina pakub Guybrush mängu laadimise ajal, et ta jutustab paari sõnaga lahti mis salvestamise eel toimunud on. See on tegelikult üsna teretulnud siis kui salvestatud mänge on hulgim või kui mängukordade vahele on tekkinud pikem paus ning ei pruugi enam täpselt meeles olla mis teoksil.

Ehk siis kokkuvõtvalt: kui esimesed kaks osa meeldisid, meeldib ka see mäng. Kuigi tehnilised on mäng suhteliselt minimalistlik immitseb sisu ja atmosfääriga seotud kvaliteeti igast mängitud sekundist, mistap ma ei saa muud teha kui seda kindlasti soovitada.

Ning lisaks räägivad kurjad keeled, et see lugu ei jää viimaseks ning autoritel on juba uus mäng tulel.

PHP 8.1: Readonly

PHP

Seekordseks teemaks on PHP 8.1-s sisse toodud uus piirang mille aluseks on readonly muutujad (propertyd).

Kes ei tea, siis readonly muutujat ei saa pärast initsialiseerimist enam muuta, funktsionaalsus mida üsna sageli läheb vaja siis kui andmeid komponentide vahel vahetatakse. Kuni viimase ajani saavutati see funktsionaalsuse getterite ja setteritega. Ma toon ühe näite readonlyst:

<?php

class Test
{
    public readonly string $test;

    public function update(string $test): void
    {
        $this->test = $test;
    }
}

$test = new Test();
$test->update('test');
echo "Initalize";
$test->update('test');
echo "Overwrite";

Kui järgnev kood lasta läbi PHP 8.1-e (varasemate versioonidega ei tööta see üldse), on tulemuseks:

Initalize
Fatal error: Uncaught Error: Cannot modify readonly property Test::$test in /data01/virt58215/domeenid/www.discordia.ee/dev/test.php:9
Stack trace:
#0 /data01/virt58215/domeenid/www.discordia.ee/dev/test.php(16): Test->update('test')
#1 {main}
  thrown in /data01/virt58215/domeenid/www.discordia.ee/dev/test.php on line 9

Nagu näha funktsiooni mis readonly muutujat modifitseerib teistkordne väljakutsumine viskab oodatult exceptioni.

Aga.

Sellel on ka üsna tülikas kõrvalnäht; nimelt on readonly nüüd reserveeritud sõna, mis praktikas tähendab seda, et kui kui teha selline klass:

<?php

class ReadOnly
{
}

… annab interpreteerimisel tulemuse:

Parse error: syntax error, unexpected token "readonly", expecting identifier in /data01/virt58215/domeenid/www.discordia.ee/dev/readonly.php on line 3

Miks see oluline on?

Oluline on see sellepärast, et päris suur hulk erinevaid rakendusi kasutavad ReadOnly klassi kasutajaliideses vaid lugemiseks mõeldud vormielemendi deklareerimiseks. Siinkohas oleks paslik märkida, et see võtmesõna on tõstutundetu, ehk siis sama viga tuleb ka READONLY, readonly, READonly, jne. puhul. Ning siis kui me tahame luua sellenimelisi traite, interfacesi, jne.

Seal on ka üks kentsakas erand: PHP 8.1 lubab deklareerida readonly() funktsioone. Põhjuseks see, et maailma kõige populaarsem sisuhaldusplatvorm WordPress kasutab seda nõnda laialdaselt, et PHP arendajatel ei olnud muud valikut kui seda eraldi lubada.

Jõulud Ukrainas

Kui vahetult enne venelaste sissemarssi Ukrainasse hakkasid levima kõlakad peatsest rünnakust, siis ma ausalt öeldes ei uskunud neid: ukrainlased on sõjakas rahvas kes selleks ajaks oli juba 8 aastat Donbassi piirkonas oma vimma idanaabrite suhtes kogunud. Pealegi on Ukraina ainult kolm korda väiksem kui Venemaa ning valmis kõik oma ressursid sõltumatuse nimel mängu panema. Kui panna siia juurde liitlassuhted ning kultuurilised erinevused siis võib öelda, et Venemaa tungis kallale endaga võrdsele. Strateegiliselt väga mõttetu liigutus ja seega ebaloogiline.

Ometigi vurasid tankid 24. veebruaril üle Ukraina-Vene piiri.

Tagantjärele tarkusena võib öelda, et mu eeldused olid siiski õiged. Selleks hetkeks kui esmane hoog rauges sai selgeks, et praktiliselt kõik Moskva eeldused osutusid valedeks: et iseseisvus pole mitte rahva vaid valitseva kliki tahe, et ukrainlastel pole tahtmist ega vahendeid võidelda, et liitlased vangutavad lihtsalt pead ja teatavad, et nad on äärmiselt mures. Ja loomulikult seda, et Venemaal ei voha korruptsioon ja alkoholism. Oma osa oli siin täita ka Eestil kes esimesena teatas, et Ukrainat tuleb aidata ning isikliku eeskujuna andsime neile OMA kaitseks mõeldud relvi ja laskemoona.

Pool aastat hiljem augustis pärast Põhja-Ukraina täieliku vabastamist sai üldsusele selgeks, et sõda kui selline on tegelikult läbi ning venelased on selle kaotanud. Sellest sai aru üldsus, sellest sai aru Ukraina ja tegelikult sai sellest ka aru Venemaa sõjavägi. Oli saabunud paras aeg leida kompromiss, ohverdada paar ettutit ja taanduda minimaalsete kaotuste hinnaga. Aga nagu selles sõjas juba kombeks oli saanud valiti risti vastupidine suund: kuulutati välja “osaline” mobilisatsioon, vahetati välja sõjaväe juhtkond, ähvardati tuumarelvaga ning keerati kinni gaasikraanid.

Ning visati minema võimalus leida mõlemat osapoolt mingilgi tasemel rahuldav kompromiss.

Selle mõtlematu teo tagajärjed ei andnud kaua oodata: rindel hukkunute arv kahe või isegi kolmekordistus peaaegu üleöö ning äkitselt jõudis sõda Venemaal igaüheni. See ei olnud enam telerist nähtav propaganda, see oli muutunud igapäevareaalsuseks koos kõigi oma koledustega. Sama loomulikult kehtis ka ukrainlaste kohta, aga neil polnud kogu ettevõtmisest mingeid illusioone, nende jaoks oli algusest peale tegemist inimsusevastase kuriteoga. Sajad ja tuhanded inimesed hukkusid iga päev sõjas mille võitja ja kaotaja olid selleks hetkeks juba selged.

Aga mitte sellest ei tahtnud ma rääkida. Seega kerime edasi tänasesse päeva ning arutame mõningasi praeguseid teemasi.

Herson

Hersoni oblast oli üks neljast Venemaa poolt annekteeritud territooriumist vaatamata sellele, et see polnud tervikuna okupantide kätte langenud. Hersoni linn oli ainuke oblastikeskus mis kogu operatsiooni käigus anastajale loovitati. Selle kaotamine oleks venelaste jaoks märgilise tähendusega.

Herson asub Dnepri jõe parem- ehk läänekaldal ja tegemist on umbes Tallinna suuruse linnaga. Sealkandis kasvatatakse suur osa arbuuse mis seletab miks need sel aastal meie poelettidelt puudusid. Venelaste jaoks oli Hersoni linn vaheetapp hõivamaks Odessa ning sõjategevuse peatumine vaid sajakonna kilomeetri kaugusel Dnepri jõest seadis venelased seal äärmiselt ebameeldivasse olukorda.

Mõistmaks mida kujutab endast Dnepr piisab pilgu viskamisest kaardil. Suur osa sellest jõest on umbes poole kilomeetri laiune mis teeb selle laiemaks enamustest Eesti järvedest. Tegemist on loodusliku tõkkega mis on ideaalne siis kui vaenlane on selle taga ja äärgmiselt ebameeldiv kui see ise asub selja taga. Kuna tegemist on nõnda laia jõega, siis viib sellest üle vaid käputäis sildasi millest enamus on konflikti käigus puruks pommitatud. Ainukesena on praeguseks säilinud Kahhovka tamm mille taga asub Kahhovka veehoidla. Venelased on Dnepri läänekalda kaitsmiseks vedanud sinna ohtralt vägesi ja tehnikad mida ei suudeta enam ka parima tahtmise juures varustada.

Mis omakorda on viinud selleni kus okupantidel on tekkinud dilemma: kas kaotada tapetute ning vangistatuna mitukümmend tuhat meest ja kaotada Herson või taanduda ja kaotada Herson. Paarikümne tuhande mehe kaotamine loetud päevade jooksul oleks Venemaa jaoks täielik krahh ning sisepoliitiliselt kui strateegiliselt. Odessa vallutamisest ei ole antud hetkel mõtet enam isegi unistada.

Aga see ei ole ainuke probleem mis neil on. Teine asi on Kahhovka veehoidla. Lisaks hüdroelektrijaamale toimib hiiglaslik veehoidla ka inimtekkelise barjäärina kaitstes Musta mere kaldal asuvaid Moskva vägesi ukrainlaste pealetungi eest. Lisaks väljub sellest kanal mis varustab Krimmi veega ning kuna vask- ehk idakallas on madalamal kui Herson, siis tammi avamisega oleks võimalik vesi peale lasta suurele osale okupantide poolt hõivatud territooriumile. Sestap võib öelda, et venelaste plaan loobuda paremkaldast oli plaan nutuga kurgus.

Ning me ei hakka rääkima siin isegi sellest, et Hersonist on jämedamate torudega võimalik avaldada oma arvamust kõige kohta mis liigub Krimmist mandrile ja vastupidi.

Lühidalt: kas venelased annavad Hersoni ära? Kui see neist kuidagi sõltuks siis ei. Ukrainlased on seal alustanud järjekordset pealetungi ja Moskva teab, et nad ei suuda seda linna ka parima tahtmise juures hoida. Sestap tehakse seal hetkel nägu, et see kõik on plaanikohane paanikavaba manööver.

Valgevene

Hiljuti jooksis meediast läbi jutt kuidas venelased viisid Valgevenesse juurde oma vägesi ning spekuleeriti võimalusega, et Valgevene liitub konfliktiga. Ma pean tunnistama, et Valgevene võimuladvik sai juba algusest peale aimu kust tuul puhub ja sestap nad on väga ettevaatlikult hoidnud oma käsi otseselt veriseks tegemast. Tõsi, nende territooriumi on kasutatud Ukraina ründamiseks kuid ise pole nad mitte ühtegi pauku teinud.

Nüüd kus Venemaa kaotus on ainult vormistamise küsimus on õhku tekkinud küsimus mis saab Valgevenest. Lukašenka on vana rebane ja päris kindlasti ei liitu ta viimasel hetkel kaotajatega. Kuna kompromissikaart on tema jaoks endiselt laual, siis suure tõenäosusega võib juhtuda, et Valgevene tahab ennast Venemaast distantseerida. Moskva jaoks oleks see võrdlemisi valus hoop ning arvatavasti selle vältimiseks sinna hetkel vägesi sisse viiaksegi. Isegi praegu saab Valgevene väita, et kõik tema sõnad ja teod tehti relva ähvardusel ning suures plaanis on nad teinud Ukrainale teene sidudes endaga hulgaliselt väeosi, mis muidu oleks saadetud Ukrainasse.

Talvesõda

Kuigi Ukraina asub Musta mere ääres on talvekülmad seal tihti sama krõbedad kui meil siin. Sel ajal kui Moskva pajatas lühiajalisest sõjalisest operatsioonist varus Kiiev ja liitlased talvevarustust. Tallinnas on hetkel 11 kraadi sooja, Hersonis 10.

Teine teema on sügis, mis sealsed maad mülkaks muudab. See ei ole probleem raudtee ja kergemate sõidutkite jaoks kuid raskemate tankide ning kütuseveokite jaoks see on kriis. Mis tähendab seda, mõnda aega rasketehnika millale venelased on oma panused teinud seal ei liigu. Muide kas te teate kui palju üks tank vajab kütust 100 kilomeetri läbimiseks? Sõltuvalt tankist 300-600 liitrit. Ehk siis senikaua kuniks maa külmab ja transpordiliinid taastuvad hõivavad külamehed taaskord taandumisel hüljatud inventari.

Donetsk

Kas te teate, et Donetski oblasti pealinn Donetsk asub vaid kiviviske kaugusel rindejoonest ning piisab vaid ühest õnnestunud läbimurdest, et see taaskord ukrainlaste kätte langeks. Tegemist oleks taaskord märgilise tähendusega sündmusega, sest Donetsk oli okupantide valduses juba enne praeguse konflikti algust ning oleks omamoodi aknaks Mariupoli. Selle hõivamine tekitaks siseriiklikult hulgalisi küsimus: miks seda konflikti ikkagi alustati? Sestap üritavad Wagner mis on arvatavasti paremini varustatud kui regulaarväeosad sealset rinnet hambad tangis edasi lükata.

Sedavõrd kuidas saabub talv ja kasvab ukrainlaste enesekindlus on tõenäoline, et just siin üritatakse järgmist suuremat läbimurret teha ning on täiesti võimalik, et osaliselt just selle liini tugevdamiseks taanduvad venelased Hersonist.

Transnistria

Transnistria on omamoodi fenomen. See kuulub ametlikult Moldovale, aga Vene separatistid on seal loonud oma järjekordse sõltumatu vabariigi. Selle käigus kerkis ülesse relvastatud konflikt mis päädis Vene baaside sinna viimisega. Seega on oma olemuselt tegemist okupeeritud territooriumiga.

Samas on aeg edasi läinud, noored on äärmiselt vaesest Transnistriast juba ammu jalga lasknud ja ainsad elanikud kes sinna on jäänud, on pensionärid. Nüüd tuleb mängu huvitav osa — Transnistria asub täpselt Moldova ja Ukraina vahel ning Ukraina võib ja ilmselt otsustabki ühel hetkel, et see järjekordne isehakanud riik koos sealsete baasidega on ohuks nende julgeolekule. Sealne Vene kontingent oleks Ukraina vastu suhteliselt abitu; seda enam, et Moskval pole ukrainlasi mitte millegagi enam ähvardada. Ning kui Moldova ametlikult kätt ette ei pane — milleks tal pole põhjust — lakkab enklaav aasta jooksul eksisteerimast.

Venemaa

Hiljuti viidi Moskvas läbi tänavaküsitlus, et mis saab siin kui Venemaa kaotab sõja Ukrainaga. Isegi kõige tulisemad sõjavastased ei saanud sellest küsimusest aru — see oli nende jaoks võimalis mis oli nende jaoks juba eos välistatud. Ma arvan, et senikaua kuniks selline seisukoht on valdav ei ole mõtet lahendust otsida. Kõigepealt peab rahvale kohale jõudma, et kaotus on täiesti arvestatav võimalus. Hinnanguliselt peab sõda selleks ajaks jõudma peaaegu igasse peressem iga inimeseni mis tähendab praktikas kusagil 200000-3000000 hukkunud ning sellega vastavas suhtarvus haavatuid, vaimselt/füüsiliselt sandistunuid, vangi langenuid, ülejooksnuid, deserteerunuid.

Praeguse tempo juures jõuab see kohale jõuludeks-aastavahetuseks. Senikaua võtab vikatimees seal paraku lõivu.

PHP8: tüübimaagia

PHP

PHP8 tõi sisse hulgaliselt täiendusi tüüpidega majandamisesse ning PHP8.1 lisas sinna omakorda peale täiendava kihi. Selles postituses keskendume me siiski vaid PHP8 muudatustel.

PHP on n.ö. nõrkade tüüpidega (weak typing) keel, mis praktikast tähendab seda, et erinevaid tüüpe on võimalik võrrelda ja nende väärtuseid teineteisele omistada; selleks vajalik tüüpide kantimine (type coercion) toimub automaatselt. Teinekord paraku soovimatute kõrvalnähtudega. PHP8 üritab jõudumööda neid soovimatuid kõrvaltoimed kas siis vältida või vähemalt pakub võimaluse neid kontrolli all hoida.

Tüüpide võrdlemine

Klassikaline erinevus PHP7 ja PHP8 vahel ilmneb järgnevas võrdluses:

if ('something' == 0) {
    echo 'true';
} else {
    echo 'false';
}

Nii 'something' kui 0 võivad olla muutujad; PHP7 puhul on vastuseks true, PHP8 puhul false. Asi on selles, et kui võrdluses on int ja string, siis proovitakse stringist teha int. Kuna tegemist on mittenumbrilise tekstiga, siis PHP7 pani selle väärtuseks 0 sellal kui PHP8 jaoks väärtus puudub ja sellest ka erinev tulemus. Samasuguse tulemuse annab näites järgnev lõik:

if ('42something' == 42) {
    echo 'true';
} else {
    echo 'false';
}

Selline tüüpide kantimine on teinekord väga mugav, näiteks XML failide töötlemisel, kuid sisaldab endas riske ja tänu sellele võib juhtuda, et kood mis toimis PHP7-s ei tööta enam PHP8-s. Märkuseks nii paljud, et:

if ('42' == 42) {
    echo 'true';
} else {
    echo 'false;
}

… on true vaatamata PHP versioonile, kuna ’42’ on string mida on võimalik üheselt intiks kantida.

Muudatus tüüpide kantimises torkab silma ka siis kui kasutada < ja > võrdluseid. Kui varem kanditi string intiks ja seejärel võrreldi, siis nüüd kui stringi ei ole võimalik konvertida on number alati väiksem kui string. Need nüansid laienevad muudelegi võrdlustele, näiteks in_array käitub nüüd pisut erinevalt.

Ma siiski tooks enne järgmise näite juurde minekut eraldi välja erisuse kui kasutada switchi.

switch(0) {
    case 'a' : print "case A\n"; break;
    case 0   : print "case 0\n"; break;
}
 
switch('a') {
    case 'a' : print "case A\n"; break;
    case 0   : print "case 0\n"; break;
}
 
switch(0) {
    case 0   : print "case 0\n"; break;
    case 'a' : print "case A\n"; break;
}
 
switch('a') {
    case 0   : print "case 0\n"; break;
    case 'a' : print "case A\n"; break;
}

Annab PHP7 puhul tulemuseks

case A
case A
case 0
case 0

ja PHP 8 puhul

case 0
case A
case 0
case A

Mis on eelnevat arvestades igati loogiline ja enamasti ka soovitud tulemus. Ehk siis nõrkade tüüpidega manipuleerides võib juhtuda, et kood käitub pisut teisi.

Unionid

PHP7 tõi keelde funktsioonide pöördumistüübi ning PHP7.1 nullitavad tüübid (nullable types). Et vältida soovimatut tüüpide kantimist ning aidata IDE-si soovituste andmisel on funktsioonidel võimalik anda tüüp nii sisendi kui väljundi jaoks. Nullitavad tüübid (algavad ? märgiga) näitavad, et tüüp võib (näiteks kui vastus ei leita) olla ka null. Näide:

public function doStuff(int $i): ?string
{
    // stuff
}

Aga mis siis kui sisend (või väljund) võib olla rohkem kui ühte tüüpi? Iseenesest pole midagi valesti selles kui muutujaid kanditakse enne või pärast funktsiooni välja kutsumist kuid see on tülikas, lisab ballasti ja ei aita loetavusele kaasa. Sestap tõi PHP8 sisse unionid. Näide:

public function add(int|float $a, int|float $b): int|float
{
    return $a + $b;
}

Märkuseks niipalju, et null ei tegelikult tüüp, vaid tüübi puudumine ja sestap ei ole string|null endiselt korrektne konstruktsioon ja selle asemel tuleks kasutada ?string tüüpi.

mixed tüüp

Teinekord on vaja lihtsalt konstruktsiooni kus lubatud on kõik tüübid KAASA ARVATUD null. Selleks puhuks tõi PHP8 sisse pseudotüübi nimega mixed. Näiteks:

public function doStuff(mixed $input): bool
{
    // stuff
}

Muutujad mille tüüp pole veel selge tüüp on samuti mixed. Kuna mixed sisaldab kõiki tüüpe ei oma int|mixed ja ?mixed mingit tähendust ning annavad seetõttu vea. Samal põhjusel ei eksisteeri is_mixed funktsiooni ning samuti ei ole võimalik teha $b = (mixed)$a.

Üks asi veel: alatest PHP8-st ei ole enam võimalik deklareerida klassi nimega mixed. Kuni sinnamaani oli see teoreetiliselt võimalik.

PHP8: konstruktori parameetrite eskaleerimine

PHP

Konstruktori parameetrite eskaleerimine (Constructor Property Promotion) on tõenäoliselt kõige praktilisem uuendus mille PHP8 endaga kaasa tõi. Ühes dependency injectionite ja reflectionite järjest laialdasema kasutamisega näeb tavalise konstruktori signatuur koos parameetrite, muutujate ja omistustega välja umbes selline:

protected Database $database;
protected Config $config;
protected Source $source;

public function __construct(Database $database, Config $config, Source $source)
{
    $this->database = $database;
    $this->config = $config;
    $this->source = $source;

ning objekti enda initsialiseerimine selle klassi põhjal selline:

$adapter = new Adapter($database, $config, $source);

Keerukamate rakenduste puhul kasutavad objektid kümneid muid objekte eriti kui mängus on reflectionid mis initsialiseerimise poole suuresti automatiseerivad ja arendajat seoserägastikuga kaasnevast peavalust säästavad. Paraku tingib see samas olukorra kus injectioneid tehakse väga kergekäeliselt ning iga klassi konstruktoris on hulgaliselt parameetreid mis siis ükshaaval klassimuutujate külge kleebitakse. Ning tõsisemates raamistikes / rakendustes on klasse sadu kui mitte tuhandeid.

See on nüri, see võtab aega, see muudab koodi pikaks ja ühes sellega loetamatuks.

PHP8-s näeb analoogne kood välja selline:

public function __construct(protected Database $database, protected Config $config, protected Source $source)
{

Kui erandjuhud näiteks referentside (need & märgiga algavad muutujad) näol kõrvale jätta, on parameetrites deklareeritud muutujate skoop ja ühes sellega nähtavus alati piiratud funktsiooniga. Erandiks on PHP8-s konstruktor kus nähtavuse lisamine ütleb klassile, et nähtavusega muutujad tuleb automaatselt eskaleerida klassiüleseks ning nende nähtavus (private, protected, public) oleks mida iganes nende nähtavuseks määrati. Muutujad millel nähtavust pole jäävad endiselt vaid konstruktorile endale nähtavaks.

Nagu näha on see tükk maad lühem, loetavam ja suures plaanis on seal palju vähem ruumi vigadele. Seal on siiski mõned nüansid millega peab arvestama:

  1. Eskaleerivaid muutjaid saab deklareerida AINULT konstruktoris
  2. Nõnda deklareeritud muutujaid EI SAA uuesti (eraldi) deklareerida
  3. Variadic muutujaid EI SAA eskaleerida
  4. Callable tüüpi muutujaid EI SAA eskaleerida
  5. Abstract konstruktorid EI TOETA eskaleerimist.

Enamus neist ülaltoodud piirangutes on tegelikult äärmiselt loogilised ning kui nende üle mõelda aitavad mõista eskaleerimise olemust. Seega eskaleerigem mõnuga!

PHP8: nullikindel operaator

PHP

Vajadus nullikindla operaatori (null-safe operator) järele eksisteerib PHP-s juba mõnda aega. Põhimõtteliselt võimaldab see nüüd kasutada pöördumisväärtuste ahelat ilma täiendavate kontrollideta ka siis kui seda kasutatakse koos väärtustamata tüüpidega (nullable types).

Et sellest paremini aru saada tuleb vaadata mõlemat asja eraldi. Väärtustamata tüübid lisati PHP-sse hulk aastaid tagasi versioonis 7.1. Klassikaline väärtustamata tüübiga meetodi signatuur näeb välja selline:

public function getSession(): ?Session
{
    // Code
}

Praktikas tähendab see seda, et kirjeldatud funktsioonil võib olla kahte tüüpi pöördumisväärtus: Session või null. Null on spetsiifiline tüüp mida kasutatakse sellistel puhkudel kui väärtust ei leita: näiteks antud juhul oleks täiesti legitiimne viis tagastada null kui sessioon on initsialiseerimata. Siinkohas on oluline mõista, et see on legitiimne viis ainult siis kui tõepoolest selline olukord on loomulik voo osa, näiteks sellisel puhul kui kasutaja pole sisse loginud. Kui sessiooni ei ole ühel või teisel (tehnilisel) põhjusel võimalik pärida, siis on korrektseks lahenduseks Exceptioni viskamine. See võimaldab vahet teha vastuse puudumisel ja veal.

Tähelepanuks niipalju, et väärtustamata tüüpe võib kasutada ka sisendaväärtustena. Näiteks:

$user->setAddress(?Address $address);

Tüüpide kasutamine pole tänapäeva PHP-s küll otseselt kohustuslik kuid sellele vaatamata rangelt soovituslik; see võimaldab IDE-del automaatselt tuvastada koodis vigu ning vältida olukorda kus funktsioonile antakse ette vale parameeter mille PHP automaatselt ootamatute tagajärgedega enda jaoks sobivaks konverteerib.

Pöördumisväärtuste ahel on PHP veelgi kauem eksisteerinud. Klassikaline ahel näeb välja selline:

$country = $app->getSession()->getUser()->getAddress()->getCountry();

See võimaldab juhul kui pöördumisväärtuseks on objekt selle meetodeid koheselt kasutada. Probleem tekib siis kui mõne meetodi pöördumisväärtuseks on null. Sellistel puhkudel on tulemuseks: Fatal error: Uncaught Error: Call to a member function getSession() on null in .... Kuna eelnevalt sai toonitatud, et null võib olla meetodil täiesti legitiimne pöördumisväärtus sunnib see arendajat iga pöördumisväärtust eraldi kontrollima mis oma olemusel muudaks kogu kontseptsiooni kasutuks.

PHP8 tõi sellele probleemile lahenduse nullikindlate operaatorite (null-safe operators) näol. Praktikas näeb see välja selline:

$country = $app->getSession()?->getUser()?->getAddress()?->getCountry();

Sellisel puhul kui ükskõik milline ülaltoodud meetod annab tagasi null väärtuse, lõpetatakse ilma veata ahela edasine täitmine ning muutuja $country saab väärtuseks null. Selline lähenemine muudab koodi oluliselt lühemaks ja loetavamaks.

Oluline on siiski pidada silmas paari nüansse:

  1. ?-> tuleks kasutada ainult siis kui pöördumisväärtus võib reaalselt null olla. Vastasel korral on see probleemi vaiba serva alla lükkamine ehk siis reaalne viga võib arenduse käigus märkamata jääda.
  2. Seda saab kasuatada ainult lugemiseks. Muutujaid selle kaudu omistada ei saa. Näiteks $country()?->countryCode = 'EE'; annab tulemuseks Fatal error: Can't use nullsafe operator in write context in …
  3. See operaator annab varasemata PHP versioonidega vea: Parse error: syntax error, unexpected '->' (T_OBJECT_OPERATOR) in …
  4. Seda meetodit ei ole võimalike kasutada läbi viidete (references): &$country->getCode(); annab tulemuseks: Fatal error: Cannot take reference of a nullsafe chain in …

PHP8: match avaldis

PHP

Ma olen viimastel aastatel päris palju pidanud algajate arendajate koodi hindama ja üks asi mis mulle silma torkab on see kui harva kasutatakse switch-i tingimuste lahendamiseks. Selle asemel leiab koodist erineval kujul terve leegioni if, else ja elseif lauseid. Ma ei hakka sellest hetkel pikemalt pajatama; jätke lihtsalt meelde, et switch on teie sõber. Kui seda õigesti kasutada siis muudab see koodi loetavamaks ja lühemaks.

PHP8 tõi sisse uue viisi tingimustega tegelemiseks mis on segu switch-ist ja kolmekordsetest (ternary) operaatoritest. Kui ei tule kohe meelde mida kolmekordne operaator endast kujutab, siis tüüpiliselt näeb see välja selline:

$i = $condition ? 'true' : 'false';

Uue viisi nimi on match ja kui tingimused klapivad, siis muudab see koodi veelgi lühemaks ja veelgi loetavamaks. Pidage meeles, et iga rida koodi on midagi mida tuleb jooksvalt hooldada ja vajaduse korral uuendada. Kui loetavus sellest ei kannata, siis mida vähem koodi seda parem. Toon siinkohas ühe näite kasutades eelmises postituses mainitud anonüümseid funktsioone:

$animal = 'dog';

$voice = match($animal) {
    'dog' => function() {return 'woof';},
    'cat' => function() {return 'meow';},
    'poro' => function() {return 'perkele!';},
    default => function() {return 'huh?';}
};

echo $voice();

Siinkohas oleks paslik ära märkida paar nüanssi. Esiteks match eeldab, et muutuja $animal on deklareeritud. Kuigi ta selle peale tööd ei katkesta ning väärtustab tulemi default-iga, kuvab ta vaikimisi hoiatuse: Warning: Undefined variable $animal

Teiseks on oluline, et match-i parameeter ja väärtus millega võrreldakse ('dog', 'cat', jne.) oleks sama tüüpi. Näiteks kui võrrelda väärtuseid 1 ja '1', siis on tulemuseks default. See on sarnane PHP === võrdlusega, kus erinevaid tüüpe ei ühtlustata nagu tehakse == võrdluse puhul.

Kolmandaks PEAB valik sisaldama tõest väärtust (kasvõi default-i näol). Kui lahendit ei leita on tulemuseks: Fatal error: Uncaught UnhandledMatchError: Unhandled match value of type string in ...

Teinekord kasutavad arendajad analoogse tulemuse jaoks nimelisi massiive:

$animal = 'dog';
$voices = [
    'dog' => function() {return 'woof';},
    'cat' => function() {return 'meow';},
    'poro' => function() {return 'perkele!';}
];

echo $voices[$animal]();

Sellel on kaks eelist: esiteks nagu näha on see ilma kontrollideta veelgi lühem ja teiseks töötab see varajasemate PHP versioonidega. Samas ei toeta see default-i mis praktikas tähendab seda, et tuleb kontrollida kas sellise nimega element eksisteerib, funktsioonid deklareeritakse isegi siis kui neid ei kasutata (see ei ole probleem kui väärtuseks on skalaarmuutujad nagu int, float, string jne.) ja tüüpi ei kontrollita. Sellise lahenduse kasutamine on iseenesest samuti ok ehk siis valik tuleb teha lähtuvalt ülaltoodud piirangutest.

Pages:1234567...145