pronto.ee

Tomorrow will be cancelled due to lack of interest

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.

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.

PHP8: create_function() eemaldati

PHP

Ma olen viimased kuu aega PHP8 sees ringi mütanud eesmärgiga aru saada mis sealt uut leiab ja kuidas sellest võimalikult palju kasu lõigata ning olen sealt leidnud päris mitu tähelepanu väärivad asjad. Püüan osadest neist paari sõnaga kirjutada.

Selle konkreetse postituse teemaks on create_function() nimeline funktsioon, õigemini selle puudumine PHP8-s. Algselt lisati see PHP4-le ning selle mõte oli tuua PHP-sse anonüümsed funktsioonid. PHP5-e viimastes versioonides muudeti see kõik juba keele osaks, kuid mingil seletamatul põhjusel jätkas suur hulk arendajaid selle funktsiooni kasutamist vaatamata sellele, et funktsiooni MITTE kasutamiseks oli päris mitu head põhjust; näiteks kasutab nõnda loodud funktsioon globaalset mälu ning seda ei ole võimalik vabastada. Kuna tegemist on jõhkra häkiga kuulutati see PHP 7.2-s eemaldamisele minevaks ning alates PHP8-st kustutati see üldse maha.

Mis omakorda tähendas seda, et kui PHP-s kirjutatud tarkvara kasutas seda funktsiooni tervitab selle kasutajat pärast uuendamist järgmine veateade: Uncaught Error: Call to undefined function create_function() in <fail>. Kuna pahatihti kasutasid seda WordPressi kujunduste ja moodulite kirjutajad tähendas see seda, et pärast PHP versiooni vahetamist loobus nii mõnigi veebisait koostööst. Eriti siis kui tegemist oli pikemat aega toiminud leheküljega ja vaatamata sellele, et platvorm ise oli viimase versiooni peal.

Õnneks on seda probleemi suhteliselt hõlbus parandada. Panen siia ülesse ühe näite. Kõigepeal näide mis PHP8-s EI tööta:

$function = create_function('$a,$b','return $a . \' \' . $b;');
echo $function('Hello', 'World!');

Ja nüüd näide mis töötab:

$function = function($a, $b) {return $a . ' ' . $b;};
echo $function('Hello', 'World!');

Nagu näha on teine näide loetavam, elegantsem ja võtab vähem ressursse. Ning selle juurutamine ei ole üldse keeruline.

Ehk on abiks.

Upgrading to Magento 1.9.4.0, PHP 7.2 compatibility problem

Magento
Magento

Magento 1.9.4.0 should support PHP 7.2 and fortunately it mostly does. However there’s an upgrade script from older Magento versions which, lets say, has room for improvements.

When your original Magento is old enough (I tested it on Magento 1.7.0.2) the process will throw following error message:

Fatal error: Uncaught Error: [] operator not supported for strings in /magento-path/app/code/core/Mage/Usa/sql/usa_setup/upgrade-1.6.0.1-1.6.0.2.php on line 93
( ! ) Error: [] operator not supported for strings in /magento-path/app/code/core/Mage/Usa/sql/usa_setup/upgrade-1.6.0.1-1.6.0.2.php on line 93

The culprit of the message above is here:

    $newValue = '';
    if (stripos($oldValue['path'], 'free_method') && isset($oldToNewMethodCodesMap[$oldValue['value']])) {
        $newValue = $oldToNewMethodCodesMap[$oldValue['value']];
    } else if (stripos($oldValue['path'], 'allowed_methods')) {
        foreach (explode(',', $oldValue['value']) as $shippingMethod) {
            if (isset($oldToNewMethodCodesMap[$shippingMethod])) {
                $newValue[] = $oldToNewMethodCodesMap[$shippingMethod];
            }
        }
        $newValue = implode($newValue, ',');
    } else {
        continue;
    }

As you can see $newValue is declared as a string and almost immediately expected to be an array (provided that conditions are right). No good. Simplest way to resolve it is to redeclare it as an array when it happens:

    $newValue = '';
    if (stripos($oldValue['path'], 'free_method') && isset($oldToNewMethodCodesMap[$oldValue['value']])) {
        $newValue = $oldToNewMethodCodesMap[$oldValue['value']];
    } else if (stripos($oldValue['path'], 'allowed_methods')) {
        $newValue = [];
        foreach (explode(',', $oldValue['value']) as $shippingMethod) {
            if (isset($oldToNewMethodCodesMap[$shippingMethod])) {
                $newValue[] = $oldToNewMethodCodesMap[$shippingMethod];
            }
        }
        $newValue = implode($newValue, ',');
    } else {
        continue;
    }

Intervjuu

Eelmise aasta lõpus tegi Andres Kütt minuga intervjuu teemal Eesti infotehnoloogiamaastiku ajalugu enne ja pärast taasiseseisvumist. See on nüüd SoundCloudis üleval ja paar korda asukohta vahetanud.

Ma soovitan asjale kõrva peale visata.

Panen siia igaks juhuks ka lingi: https://soundcloud.com/memcpy_podcast/memcpy-1-pronto/

Magento: SUPEE-10752 v1 breaks Zend_Filter_PregReplace

There’s a chance that after installing SUPEE-10752v1 you might run into following error message:

Warning: substr() expects parameter 1 to be string, array given in /magento_root/app/code/core/Zend/Filter/PregReplace.php on line 173


This file was introduced as a part of SUPEE-10752v1 patch and it adds some deprecation modifier checks:

    /**
     * Perform regexp replacement as filter
     *
     * @param  string $value
     * @return string
     */
    public function filter($value)
    {
        if ($this->_matchPattern == null) {
            #require_once 'Zend/Filter/Exception.php';
            throw new Zend_Filter_Exception(get_class($this) . ' does not have a valid MatchPattern set.');
        }
        $firstDilimeter = substr($this->_matchPattern, 0, 1);
        $partsOfRegex = explode($firstDilimeter, $this->_matchPattern);
        $modifiers = array_pop($partsOfRegex);
        if ($modifiers != str_replace('e', '', $modifiers)) {
            throw new Zend_Filter_Exception(get_class($this) . ' uses deprecated modifier "/e".');
        }

        return preg_replace($this->_matchPattern, $this->_replacement, $value);
    }

It’s an override of lib/Zend/Filter/PregReplace.php and the original looks like this:

    /**
     * Perform regexp replacement as filter
     *
     * @param  string $value
     * @return string
     */
    public function filter($value)
    {
        if ($this->_matchPattern == null) {
            #require_once 'Zend/Filter/Exception.php';
            throw new Zend_Filter_Exception(get_class($this) . ' does not have a valid MatchPattern set.');
        }

        return preg_replace($this->_matchPattern, $this->_replacement, $value);
    }

As you can see, original method is indeed able to handle arrays while override is not. Objects such as lib/Zend/Filter/Word/CamelCaseToSeparator.php and lib/Zend/Filter/Word/SeparatorToCamelCase.php indeed use arrays for match patterns:

    public function filter($value)
    {
        if (self::isUnicodeSupportEnabled()) {
            parent::setMatchPattern(array('#(?<=(?:\p{Lu}))(\p{Lu}\p{Ll})#','#(?<=(?:\p{Ll}|\p{Nd}))(\p{Lu})#'));
            parent::setReplacement(array($this->_separator . '\1', $this->_separator . '\1'));
        } else {
            parent::setMatchPattern(array('#(?<=(?:[A-Z]))([A-Z]+)([A-Z][A-z])#', '#(?<=(?:[a-z0-9]))([A-Z])#'));
            parent::setReplacement(array('\1' . $this->_separator . '\2', $this->_separator . '\1'));
        }

        return parent::filter($value);
    }

While Magento itself does not use the things above some of the third party extension do, such as Ebizmarts_SagePaySuite (Zend_Filter_Word_CamelCaseToUnderscore extends Zend_Filter_Word_CamelCaseToSeparator), do. Here a sample code from app/code/local/Ebizmarts/SagePaySuite/Helper/Data.php:

    public function cameltounder($str)
    {
        $a = new Zend_Filter_Word_CamelCaseToUnderscore;

        return strtolower($a->filter($str));
    }

Solution:

Easiest way to solve this issue is to copy the file mentioned above (app/code/core/Zend/Filter/PregReplace.php) to app/code/local/Zend/Filter/PregReplace.php and replace the filter method with following:

    /**
     * Perform regexp replacement as filter
     *
     * @param string $value
     * @return string
     */
    public function filter($value)
    {
        if ($this->_matchPattern == null) {
            #require_once 'Zend/Filter/Exception.php';
            throw new Zend_Filter_Exception(get_class($this) . ' does not have a valid MatchPattern set.');
        }
        $patterns = array();
        if (is_array($this->_matchPattern)) {
            $patterns = $this->_matchPattern;
        } else {
            $patterns[] = $this->_matchPattern;
        }
        foreach($patterns as $pattern) {
            $firstDilimeter = substr($pattern, 0, 1);
            $partsOfRegex = explode($firstDilimeter, $pattern);
            $modifiers = array_pop($partsOfRegex);
            if ($modifiers != str_replace('e', '', $modifiers)) {
                throw new Zend_Filter_Exception(get_class($this) . ' uses deprecated modifier "/e".');
            }
        }
        return preg_replace($this->_matchPattern, $this->_replacement, $value);
}

I guess eventually there will be SUPEE-10752v2 which hopefully fixes this problem. Make sure to check/remove the local override when you install it.

PS. Everything above applies to Magento OS v1.9.3.9 as well.

iPhone tulevik

Igasugune ennustamine on üsnagi tänamatu tegevus. Ometigi on sellega vaja tegeleda, sest plaane on vaja teha; kas siis investorina, tarbijana või niisama huvilisena, vahel kõigi kolmena korraga. Paraku on ennustamine NII tänamatu tegevus, et targemad inimesed kardavad seda nagu Vanatühi välku ja sestap on internet täis prognoose, mis on kas siis täiesti valed või parimal juhul suurelt osalt ebatäpsed. Järgnev on siis minu panus enese lolliks tegemisse.

Sissejuhatavalt niipalju, et minu investeerimisportfellis on tõepoolest õunafirma osakuid ning mul on majapidamises kokku kolm iPhonet, kolm MacBooki, iPad ja Apple TV. Ning ma olen nende seadmetega rahul. Seega olen ma asjaga seotud nii investori, tarbija kui vähemalt enda arvates ka huvilisena.

Kuid nüüd asja juurde.

iPhone X on juubelimudel

Üks asi mis mind hämmastab on see, et inimestele ei mahu üks asi kuidagi pähe: iPhone X nagu nimigi ütleb, on juubelimudel. Seda pakuti kui kallimat ja rammusamat iPhone 8 alternatiivi inimestele, kelle jaoks raha ei ole probleem. Nagu näha kajastus see Apple äsja ilmunud finantsaruandes, kus suuresti tänu iPhone X-le roobitseti kokku taaskord rekordiline kasum. See tähendab muuhulgas ka seda, et uut iPhone X mudelit ei tule. Sest kui kaua sa seda va aasta otsa tohletanud juubelitorti ikka näsid.

Järgmine mudel ei pruugi enam iPhone nime kanda

Eelmine iPhone mudel oli 7, praegune 8. Traditsiooniliselt on uus number kasutusele võetud igal teisel aastal ning vahepealne mudel on olnud n.ö. S seeria: 4, 4S, 5, 5S, 6 ja 6S. Nagu näha jäi 7S vahele, mis on mõnevõrra üllatav, sest vahe eelmise ja praeguse mudeli vahel pole funktsionaalsuse seisukohalt eriti suur. Enamgi veel, X iPhone X-nimes ei ole mitte “iks” vaid “10”, mis külvab veelgi numeratsiooniloogikasse segadust. See kõik paistab viitavat sellele, et Apple kavatseb loobuda iPhone brändi kasutamisest, mis ei olekski väga üllatav, arvades kaotatud kohtuvaidlusi kaubamärgi üle Hiinas ja seda, et “Apple Watch” ja “Apple Pay” on juba kasutuses. Sestap võib oletada, et kas järgmine või ülejärgmine iPhone kannab juba nime Apple Phone.

Muide kui Apple kavatseb uue nime kasutusele võtta mitte see aasta, vaid järgmine, siis seda on võimalik tuvastada sellega kui nad nimetavad 2018 aasta mudeli iPhone 9-ks. Samas, see aasta on tõenäolisem kui järgmine, sest uue mudeli puhul ei piisa lihtsalt seadme ümber nimetamisest, vaja on uut ja huvitavat funktsionaalsust, uut välimust ja võib-olla veel midagi. Face ID sobiks sellesse patta suurepäraselt. Aga eks näis.

Face ID on liitreaalsuse prillide “killer application”

Selleks, et uus tehnoloogia läbi lööks on vaja midagi, mis muudaks selle tarbijate jaoks ihaldatavaks. PlayStation 3 jaoks oli see Blu-Ray mängija, Nintendo Switchi jaoks oli see “The Legend of Zelda: Breath of the Wild” mäng, jne. Enamasti on selleks mingi tarkvaralahendus, kuid see võib põhimõtteliselt olla ka riistvararakendus. Liitreaalsuse suureks probleemiks on olnud see, et tegemist on rohkem olnud leludega, millegagi, mis ei anna erilist lisaväärtust.

Face ID suure tõenäosusega muudab seda. Tegemist ei ole pelgalt biomeetrilise turvaelemendi või animeeritud emotikonidega, kaugel sellest. Kujutage ette, et te inimesega kohtudes teate ilma spetsiaalselt järgi vaatamata kõike temaga seotud: millal temaga viimati kohtusite, millega ta viimasel ajal sotsiaalmeedias silma on paistnud, mida te olete seoses temaga kokku leppinud, temaga seotud märkmeid ja palju muud. Ning seda täiesti automaatselt. Loomulikult töötab see kõik ka teistpidi, kuid kas te olete valmis selleks, et su vestluspartner teab sinust kõike ja sina temast väga vähe? Seega, killer application.

Ning ärge apelleerige privaatsusele ja sellega seotud seadusandlusele. See lakkas eksisteerimast sel hetkel kui te esimese sotsiaalmeedia konto tegite. Privaatsus on nagu hobune, see võib sind viia edasi või tagasi; kõik sõltub sellest kumba pidi setukas aiste vahele aeti.

Kuigi see aasta ilmselt Apple prille veel oodata ei ole, on täiesti võimalik, et WWDC ’18 raames kuulutatakse välja selle tarkvaraplatvorm rakenduste loojatele.

Pages:123