Keskustelu: Nettisivujen teko: PHP 7 julkaistaan vuonna 2015

PHP 7 julkaistaan jo tänä vuonna, bueno!

Dynaaminen tyypitys historiaa, mukaan tuodaan mm. scalar type hints ja paluuarvot. Käytännössä PHP-koodin yleinen taso nousee väkisin.
Ei mitä ilmeisemmin vieläkään tulossa overloading tukea..

Lisäksi ZF3 on tulossa Q3 2015 joka on: "Optimizing for PHP 7, but supporting PHP 5.5 onwards.".

ZF3 pohjautuu ilmeisesti ZF2:seen, joten osaaminen ei mene hukkaan.

class Person {

    //...

    public function __construct(string $name, int $age) {
        //...
    }

    public function getName(): string {
        return $this->name;
    }

    public function getAge(): int {
        return $this->age;
    }
}

Feature freeze on päällä 7.0:lle ja täältä löytyy kaikki sen sisältämät muutokset: https://wiki.php.net/rfc#php_70

Tuolta voisi lisäksi poimia phpng:n mikä nostaa suorituskyvyn about HHVM:n tasolle sekä Exceptions in the enginen.

PHP 6 ilmeisesti epäonnistui. Tukeeko PHP 7 UTF-8-merkistökoodausta, eli päästäänkö mb_-funktioista eroon?

Kas. Joko phpng on Phalangerin tasolla suorituskyvyssä edes? On kyllä kaivattukin vähän tehonlisäystä, puhumattakaan siitä, että olisi Ihan Kiva(tm) jos funktiot palauttaisivat vain yhtä tyyppiä.

Mutta eikö oikeasti vieläkään PHP7 tule Unikoodina, vaikka muuten rikotaan taaksepäin yhteensopivuutta?

Ja jotenkin pelkään, että rikotaan liian vähän, eli pidetään vieläkin turhaa painolastia ja sotkua mukana sen sijaan, että tehtäisi kunnollista ja nimettäisi funktiot järkevästi jne. Mutta silloin ehkä monet alkaisivat katsoa sitä vihreämpää nurmikkoa toisaalla, missä on paljon vähemmän ongelmia ja sotkuja.

Lisäys: Jännää muuten, että UTF-16 nähtiin yhtenä syynä sille, ettei PHP6 onnistunut. .NET, Java jne eivät ole kärsineet asiasta ollenkaan, joten kyllä sen olisi pitänyt onnistua. Enemmän lieni syy siinä, että liian myöhään lähdettiin tekemään, joten hankalahan sitä on muuntaa koko koodimassaa. Ja jos sitä ei tehdä nyt seiskassa, ei sitä tehdä vuosiin jatkossakaan.

feenix kirjoitti:

Kas. Joko phpng on Phalangerin tasolla suorituskyvyssä edes?

Mutulla sanottuna phpng on tehokkaampi. Phalangerin benchmarkit vuodelta 2012 (vuoden vanhoja) ja phpng:n viime kesältä.

http://www.php-compiler.net/benchmarks
http://zsuraski.blogspot.co.il/2014/07/benchmarking-phpng.html

Funktioiden nimeämistä en minäkään enää lähtisi muuttamaan, taaksepäin yhteensopivuus kuitenkin sen verran iso asia.

timoh kirjoitti:

Funktioiden nimeämistä en minäkään enää lähtisi muuttamaan, taaksepäin yhteensopivuus kuitenkin sen verran iso asia.

Ihan hyvin voisi deprekoida vanhat funktiot ja jättää ne osaksi standardikirjastoa vaikka seuraavaksi kymmeneksi vuodeksi. Vaikka erikseen ladattavana laajennuksena, jolloin se bloatti ei haittaa kaikkia muita. Tiedä sitten, millainen ongelma tuo olisi teknisesti kielen jatkokehityksen kannalta.

PHP:ssä pitäisi olla regex-datatyyppi. Nythän säännöllinen lauseke on vain tietynmuotoinen merkkijono.

Uusi datatyyppi auttaisi funktioiden nimeämistä. Voisi esimerkiksi olla funktio replace erillisten funktioiden str_replace ja preg_replace sijaan.

Laittaisivat PHP:n kunnolla risaiseksi…

HTML5 kirjoitti:

Uusi datatyyppi auttaisi funktioiden nimeämistä. Voisi esimerkiksi olla funktio replace erillisten funktioiden str_replace ja preg_replace sijaan.

Mitä hyötyä siitä varsinaisesti olisi? Ensimmäisen parametrin vaihtaminen vaatii usein muutoksia myös toiseen parametriin, joten virheen mahdollisuus kasvaisi. Esimerkki:

echo str_replace ('A',   '$1',   'ABC'), "\n"; // '$1BC'
echo str_replace ('A',   '\\$1', 'ABC'), "\n"; // '\\$1BC'
echo preg_replace('/A/', '$1',   'ABC'), "\n"; // 'BC'
echo preg_replace('/A/', '\\$1', 'ABC'), "\n"; // '$1BC'

Siis täytyy miettiä, mistä muutoksista on oikeasti hyötyä.

HTML5 kirjoitti:

Tukeeko PHP 7 UTF-8-merkistökoodausta, eli päästäänkö mb_-funktioista eroon?

Suurin ongelma tässä muutoksessa on luultavasti se, että nykyinen merkkijono voi sisältää mitä tahansa binääridataa, jolloin ei voida vain ruveta käsittelemään merkkijonoja UTF-8-tyyppisinä vaan tarvittaisiin erillinen tietotyyppi binääridatalle. Kun PHP:ssä tietotyypit muutenkin muuttuvat maagisesti toisikseen, korjattavien kohtien etsiminen koodista olisi ihan mahdotonta.

Onneksi tekstin pituutta tarvitsee aika harvoin ja esimerkiksi tekstin katkaiseminen ja monet muut asiat onnistuvat UTF-8-enkoodatussakin tekstissä tavallisilla funktioilla.

Metabolix kirjoitti:

HTML5 kirjoitti:

Uusi datatyyppi auttaisi funktioiden nimeämistä. Voisi esimerkiksi olla funktio replace erillisten funktioiden str_replace ja preg_replace sijaan.

Mitä hyötyä siitä varsinaisesti olisi? Ensimmäisen parametrin vaihtaminen vaatii usein muutoksia myös toiseen parametriin, joten virheen mahdollisuus kasvaisi.

– –

En tullut ajatelleeksi tuota. Pidän vain enemmän tavasta, jolla JavaScriptin funktiot on nimetty.

Metabolix kirjoitti:

Suurin ongelma tässä muutoksessa on luultavasti se, että nykyinen merkkijono voi sisältää mitä tahansa binääridataa, jolloin ei voida vain ruveta käsittelemään merkkijonoja UTF-8-tyyppisinä vaan tarvittaisiin erillinen tietotyyppi binääridatalle.

En tajua, miten binäärin käsittely liittyy asiaan. Php:ssä on jo nyt erikseen binary-safe-versiot funktioista, koska tekstiä käsittelevät funktiot eivät sellaisia ole muutenkaan. Periaatteessa koodarin pitäisi kyllä tietää, aikooko hän koodissaan käsitellä tekstiä vai binääridataa ja koodata sen mukaisesti. Joka tapauksessa se vaikuttaa paljon pienemmältä ongelmalta kuin se, että tekstidatan käsittelyyn on useita rinnakkaisia funktioita.

The Alchemist, PHP:ssä ei voi ”koodata sen mukaisesti”, koska on vain yksi tietotyyppi tekstille ja binääridatalle. Jos esimerkiksi luetaan tiedosto funktiolla file_get_contents tai kirjoitetaan lainausmerkkeihin "abc", ei ole mitään tapaa erottaa tekstiä ja binääridataa.

Kaivattu Unicode-tuki tarkoittaisi mielestäni, että teksti ja binääridata olisivat erilliset tietotyypit, esim. string ja bytes. (Muutenhan PHP:ssä on jo Unicode-tuki, nimittäin mbstring.) Tämä väistämättä rikkoisi suuren osan binääridataa käsittelevistä koodeista tavalla tai toisella. Jos ja kun näistä kohdista ei varmasti tulisi PHP:ssä kunnollisia virheilmoituksia vaan tapahtuisi vain automaattisia tyypinmuunnoksia, olisi työlästä etsiä koodista päivitettävät kohdat.

Esimerkiksi tässä on nykytyylistä PHP:tä, jossa tekstiä ja binääridataa käsitellään samalla tavalla:

// JSON-tiedosto; speksin mukaan UTF-8-tekstiä.
$json = json_decode(file_get_contents("data.json"));
if ($json == "Pöö") {
	echo "JSON toimii, UTF-8-tiedosto\n";
}

// tar-tiedosto; taatusti binääridataa.
$tar = file_get_contents("data.tar");
if (substr($tar, 0x101, 5) == "ustar") {
	echo "tar toimii, binääritiedosto\n";
}

Onko The Alchemistilla tähän jokin parempi tapa, jossa ei tulisi mitään ongelmia, vaikka PHP:hen lisättäisiin Unicode-tuki?

Onko The Alchemistilla jokin hieno idea Unicode-tuen toteutuksesta niin, ettei tuota koodia tarvitse muuttaa tai että muutettavista kohdista ainakin saa kelvollisia varoituksia eikä koodi bugaisi?

Metabolix kirjoitti:

Kaivattu Unicode-tuki tarkoittaisi mielestäni, että teksti ja binääridata olisivat erilliset tietotyypit, esim. string ja bytes. (Muutenhan PHP:ssä on jo Unicode-tuki, nimittäin mbstring.) Tämä väistämättä rikkoisi suuren osan binääridataa käsittelevistä koodeista tavalla tai toisella.

Minä ymmärsin että PHP7:n on tarkoitus laajemminkin korjailla dynaamisen tyypityksen ongelmia, aiempien versioiden yhteensopivuudesta niin hirveästi välittämättä. Joten toisiko tuo nyt niin hirveästi ongelmia muutenkaan?

Oskuz kirjoitti:

Minä ymmärsin että PHP7:n on tarkoitus laajemminkin korjailla dynaamisen tyypityksen ongelmia, aiempien versioiden yhteensopivuudesta niin hirveästi välittämättä.

Mitään kovin mullistavaa muutosta ei ole tulossa. Suurin parannus taitaa olla se, että myös tavalliset tyypit kuten int ja string kelpaavat parametrien tyypeiksi.

Metabolix kirjoitti:

Onneksi tekstin pituutta tarvitsee aika harvoin ja esimerkiksi tekstin katkaiseminen ja monet muut asiat onnistuvat UTF-8-enkoodatussakin tekstissä tavallisilla funktioilla.

Tuota, tavallisilla funktioilla? Tarkoitatko nyt tuota mb-modulia, vai ihan tavallista substr-funktiota? Jälkimmäisellä kun ei tosiaankaan onnistu ja ensimmäinen ei ole "tavallinen funktio."

Toki tuo moduli tarkoittaa, että PHP:ssä on Unicode-tuki, mutta aika säätämistä sen kanssa tulee, jos aikoo jotain oikeasti tehdä. Ainakin hitosti ylimääräisiä funktiokutsuja. Mutta toisaalta, väki on tottunut siellä leikkimään myös SQL-escape-funktioiden kanssa ja saamaan aikaan turhia lisääntyviä \-merkkejä ja muuta hienoa, joten eihän mitään ylimääräistä säätämistä ja ongelmia tule modulin käyttämisestä sen sijaan, että oikeasti se olisi sisäänrakennettu.

Metabolix kirjoitti:

Oskuz kirjoitti:

Minä ymmärsin että PHP7:n on tarkoitus laajemminkin korjailla dynaamisen tyypityksen ongelmia, aiempien versioiden yhteensopivuudesta niin hirveästi välittämättä.

Mitään kovin mullistavaa muutosta ei ole tulossa. Suurin parannus taitaa olla se, että myös tavalliset tyypit kuten int ja string kelpaavat parametrien tyypeiksi.

Tyypillinen kommentti sinulta. Ovathan ko. muutokset mullistavia ottaen huomioon PHP:n historia. Mikä mielestäsi sitten olisi ”mullistava” muutos?

feenix kirjoitti:

Metabolix kirjoitti:

Onneksi tekstin pituutta tarvitsee aika harvoin ja esimerkiksi tekstin katkaiseminen ja monet muut asiat onnistuvat UTF-8-enkoodatussakin tekstissä tavallisilla funktioilla.

Tuota, tavallisilla funktioilla? Tarkoitatko nyt tuota mb-modulia, vai ihan tavallista substr-funktiota? Jälkimmäisellä kun ei tosiaankaan onnistu

Miten niin ei onnistu? UTF-8:ssa on nimenomaan se ominaisuus, että mikään merkki ei voi olla toisen merkin osa, joten tavalliset funktiot strpos, substr, strlen ja explode toimivat aivan hyvin yleisimmissä käyttötarkoituksissa, jotka ovat merkkijonon osan etsiminen ja merkkijonon katkaisu tietyn alimerkkijonon kohdalta (ennen tai jälkeen).

$s = "åäö foo åäö bar åäö baz";
var_dump(explode("åäö", $s)); // Täysin odotettu tulos.
var_dump(strpos($s, "foo åäö") !== false); // Boolean-arvona aivan odotettu tulos.

$p0 = strpos($s, "foo åäö");
$p1 = strpos($s, "bar åäö") + strlen("bar åäö");
var_dump(substr($s, $p0, $p1 - $p0)); // Täysin odotettu tulos.

Siis jos kohdat haetaan strpos-funktiolla ja tekstien pituudet strlen-funktiolla, kaikki toimii. Ongelmia tulee ainoastaan silloin, kun yritetään kovakoodata jotain merkkien lukumääriä koodiin (esim. substr($s,1,2)).

qeijo kirjoitti:

Ovathan ko. muutokset mullistavia ottaen huomioon PHP:n historia. Mikä mielestäsi sitten olisi ”mullistava” muutos?

Mullistava olisi vaikka tuo bytes vs. string -erottelu. Mullistavaa olisi myös, jos esimerkiksi lauseke "1foo" + "2bar" ei tuottaisi tulosta 3 vaan virheilmoituksen viallisista luvuista.

Metabolix kirjoitti:

Miten niin ei onnistu? UTF-8:ssa on nimenomaan se ominaisuus, että mikään merkki ei voi olla toisen merkin osa, joten tavalliset funktiot strpos, substr, strlen ja explode toimivat aivan hyvin yleisimmissä käyttötarkoituksissa, jotka ovat merkkijonon osan etsiminen ja merkkijonon katkaisu tietyn alimerkkijonon kohdalta (ennen tai jälkeen).

Toisaalta jos ajatellaan tekstin katkaisua esim. 10 merkin pituiseksi, niin se ei onnistu.

qeijo kirjoitti:

Dynaaminen tyypitys historiaa, mukaan tuodaan mm. scalar type hints ja paluuarvot.

Eikö toi ole merkittävää?

Metabolix kirjoitti:

Mullistava olisi vaikka tuo bytes vs. string -erottelu. Mullistavaa olisi myös, jos esimerkiksi lauseke "1foo" + "2bar" ei tuottaisi tulosta 3 vaan virheilmoituksen viallisista luvuista.

Tuon voin muuten allekirjoittaa, paitsi virheen sijasta saataisiin: "1foo2bar".
Samantien olisivat voineet myös selkeyttää funktioiden nimeämistä, ja jakaa ne erillisiin moduuleihin. Tai edes jakaa kuvaaviin nimiavaruuksiin.
Myös toi Unicode-tuki olisi aika must ihan natiivina, vaikka ilmankin voi tulla toimeen.

Eipä natiivi Unicode-tuki loppukäyttäjän kannalta hirveästi muuta käytännön asioita. Multibyte String ajaa vastaavan asian.

$foo[1] -tyylinen haku/korvaus ei nykyisellään toimi (liekkö feenix juuri tätä tarkoittanut), mutta muuta kummempaa ei tule mieleen mitä natiivi Unicode-tuki varsinaisesti helpottaisi.

Ja mainitut SQL-escape-funktiot ja lisääntyvät \-merkit on suoraan Grandma's PHP:stä ;)

Grez kirjoitti:

Toisaalta jos ajatellaan tekstin katkaisua esim. 10 merkin pituiseksi, niin se ei onnistu.

Totta. Sanoinkin ”monet” enkä ”kaikki”.

Toisaalta tietyn merkkimäärän ottaminen tekstistä jää ratkaisuna usein puolitiehen. Jos on tarkoitus lyhentää tekstiä, täytyisi edes etsiä tavuraja, jotta tulos näyttäisi hyvältä. Tässä ei auta Unicode. Jos on tarkoitus sovittaa teksti tiettyyn tilaan, merkkimäärä ei kerro koko totuutta, koska eri merkit ovat eri kokoisia; täytyisi tietää fontti ja huomoida tekstin rivittyminen ym.

Teknisessä tekstissä (kuten vaikka HTML:ssä), jossa tietyn merkkimäärän käsittely voi olla järkevää, on taas usein (olennaisissa kohdissa) vain ASCII-merkkejä, jolloin tavalliset funktiot jälleen sopivat.

Oskuz kirjoitti:

Virheen sijasta saataisiin: "1foo2bar".

Onko sekään sitten nyt muka hyvä? Mitä sitten tuottaa "1" + "2"? Kun kerran tekstien yhdistelyyn

Metabolix kirjoitti:

Ongelmia tulee ainoastaan silloin, kun yritetään kovakoodata jotain merkkien lukumääriä koodiin (esim. substr($s,1,2)).

Eli merkkijonon vapaavalintainen katkaisu ei onnistukaan vakiofunktioilla, kuten väitit. Aina kun ei etsitä mitään merkkijonoja toisen sisältä tms, vaan vaikkapa "anna 50 ensimmäistä merkkiä." Ei onnistu.

Entäs vaikkapa combining diacritics? Jos on merkkijono "åäöe\u0308asdfe759843785" ja splittaan vakiofunktioilla, nekö jakavat tuon kahtia eikä kolmeen osaan?

$s = "asdeasde\xcc\x88asd";
var_dump(explode("e", $s)); // Täysin odottamaton tulos

Eli jos tietää täsmälleen mitä saa sisään, vakiofunktioilla voi tehdä jotain asioita. Mutta ihan turha väittää, että vakiofunktioilla UTF-8:n käsittely onnistuisi ongelmitta, puhumattakaan että Unicode olisi tuettu.

Metabolix kirjoitti:

Totta. Sanoinkin ”monet” enkä ”kaikki”.

Mutta katkaisun sanoit ennen "monet", eli sen pitäisi siis aina onnistua...

Korjaisin mieluummin: vakiofunktioilla voit etsiä tietämästäsi merkkijonosta tietämiäsi osia ja laskea niiden pituuksia tavuina sekä jakaa osiin niiden avulla, mutta jos oikeasti käytetään Unicodea, pitää käyttää laajennusfunktioita.

Oskuz kirjoitti:

qeijo kirjoitti:

Dynaaminen tyypitys historiaa, mukaan tuodaan mm. scalar type hints ja paluuarvot.

Eikö toi ole merkittävää?

qeijolla on väärää tietoa. Dynaaminen tyypitys ei muutu mihinkään. Myöskään heikko tyypitys ei muutu mihinkään. Kuten sanoin, ainoat muutokset ovat parametrien perustietotyypit ja paluuarvojen tyypit. Heikon tyypityksen mukaisesti yhä edelleen voidaan kirjoittaa "1foo" + "2bar" ja saada tulokseksi luku; tyypit muuttuvat automaattisesti. Dynaamisen tyypityksen mukaisesti yhä edelleen voidaan sijoittaa samaan muuttujaan ensin 1 ja sitten "x"; muuttujalla ei ole määrättyä tietotyyppiä.

feenix kirjoitti:

Eli merkkijonon vapaavalintainen katkaisu ei onnistukaan vakiofunktioilla, kuten väitit.

En myöskään väittänyt, että mielivaltainen katkaisu onnistuisi, vaan että katkaiseminen ylipäänsä on mahdollista. Kyseinen virke alkoi ”onneksi tekstin pituutta tarvitsee aika harvoin”, mikä jo sisältää ajatuksen, että myöskään katkaisua ei tehdä vain tekstin pituuden mukaan. Kuten juuri Grezille tähän asiaan vastasin, merkkimäärä ei useinkaan ole edes paras ratkaisu.

feenix kirjoitti:

Mutta ihan turha väittää, että vakiofunktioilla UTF-8:n käsittely onnistuisi ongelmitta, puhumattakaan että Unicode olisi tuettu.

En ole missään väittänyt, että Unicode olisi tuettu. Totesin vain, että suuressa osassa ihan todellisista järkevistä käyttötarkoituksista Unicode-tuella ei ole merkitystä. Tietenkin aina voi kehitellä tilanteita, joissa koodi toimii väärin, mutta keksipä nyt jokin järkevä todellinen tilanne, jossa teksti pitää katkaista explodella e-kirjainten kohdalta ja perässä saattaa olla combining diacritic. Näytä sitten vielä jokin kieli, jonka natiivi Unicode-tuki käsittelee tuon tilanteen oikein: yleensä koodeissa käsitellään koodipisteitä eikä näkyviä merkkejä, joten saat luultavasti väärän tuloksen suurimmalla osalla kielistä (mm. Pythonilla).

Eli jos noin ”oikeasti” halutaan käyttää Unicodea, tarvitaan kirjastoja, joiden sisällyttäminen kielen tavanomaiseen Unicode-tukeen olisi melkoista hukkaa.

Metabolix kirjoitti:

merkkimäärä ei useinkaan ole edes paras ratkaisu.

Toisaalta esim. merkkien todelliseen leveyteen perustuva katkaisu vaatii käytännössä myöskin niiden unicoodien tukemista ja aika purkkaviritykseksi voi mennä myös tavurajojen etsiminen, kun lähdetekstissä voi olla välissä esim. (Unicode-)tavumerkkejä tms. tavaraa joka sekoittaisi pelkkään tavusanakirjaan perustuvaa järjestelmää.

Mutta on kyllä totta sekin ettei täydellinen tavutus ole ihan triviaalia vaikka olisi Unicode-tukikin.

Ihan käytännön esimerkki, missä merkkimäärän katkaisu on (minun mielestäni) järkevää on esimerkiksi ottaa 50 ensimmäistä merkkiä weppisivulle johon mahtuu parhaimmillaan vaikka 45 l-kirjainta. Eli siis antaa selaimen (CSS:llä ohjeistettuna) hoitaa katkaisu sen mukaan mitä mahtuu, mutta ei toisaalta ole järkeä tunkea tuhansia merkkejä tekstiä siihen. Tässä tapauksessa tosin katkaisukohtaan voi jäädä rikkinäinen merkki. Mutta se ei kai haittaa?

Metabolix kirjoitti:

The Alchemist, PHP:ssä ei voi ”koodata sen mukaisesti”, koska on vain yksi tietotyyppi tekstille ja binääridatalle. Jos esimerkiksi luetaan tiedosto funktiolla file_get_contents tai kirjoitetaan lainausmerkkeihin "abc", ei ole mitään tapaa erottaa tekstiä ja binääridataa.

Niin, php-tulkki ei voi erottaa niitä, mutta koodari voi, koska koodari tietää lukevansa joko json-tiedostoa tai tar-palleroa.

Metabolix kirjoitti:

Kaivattu Unicode-tuki tarkoittaisi mielestäni, että teksti ja binääridata olisivat erilliset tietotyypit, esim. string ja bytes. (Muutenhan PHP:ssä on jo Unicode-tuki, nimittäin mbstring.) Tämä väistämättä rikkoisi suuren osan binääridataa käsittelevistä koodeista tavalla tai toisella. Jos ja kun näistä kohdista ei varmasti tulisi PHP:ssä kunnollisia virheilmoituksia vaan tapahtuisi vain automaattisia tyypinmuunnoksia, olisi työlästä etsiä koodista päivitettävät kohdat.

Esimerkiksi tässä on nykytyylistä PHP:tä, jossa tekstiä ja binääridataa käsitellään samalla tavalla:

// JSON-tiedosto; speksin mukaan UTF-8-tekstiä.
$json = json_decode(file_get_contents("data.json"));
if ($json == "Pöö") {
	echo "JSON toimii, UTF-8-tiedosto\n";
}

// tar-tiedosto; taatusti binääridataa.
$tar = file_get_contents("data.tar");
if (substr($tar, 0x101, 5) == "ustar") {
	echo "tar toimii, binääritiedosto\n";
}

Onko The Alchemistilla tähän jokin parempi tapa, jossa ei tulisi mitään ongelmia, vaikka PHP:hen lisättäisiin Unicode-tuki?

Onko The Alchemistilla jokin hieno idea Unicode-tuen toteutuksesta niin, ettei tuota koodia tarvitse muuttaa tai että muutettavista kohdista ainakin saa kelvollisia varoituksia eikä koodi bugaisi?

Tietääkseni en sanonut, että mikään ratkaisu ongelmaan olisi mahdollista toteuttaa ilman mittavia muutoksia vanhaan koodiin. Kirjoitin viestini siitä näkökulmasta, että jos (=koska) funktiokikkailu on pakollista jossain tilanteessa, niin olisi järkevämpää pakottaa siihen tapauksessa tekstidata vs. binääri kuin ascii vs. unicode. Varsinkin nyt emojien maailmassa unicode täytyy huomioida ihan kaikkialla, "poikkeuksetta".

Binäärityypin kanssa on sekin ongelma, että string-int-vertailussa php konvertoi merkkijonon kokonaisluvuksi (...), mutta mikä voisikaan olla tiettyä binäärijonoa vastaava kokonaislukuarvo?

The Alchemist kirjoitti:

Olisi järkevämpää pakottaa siihen tapauksessa tekstidata vs. binääri kuin ascii vs. unicode.

Hienoa, olemme samaa mieltä. Epäselväksi jäi vielä kommenttisi ”en tajua, miten binäärin käsittely liittyy asiaan”. Juuri itse vastasit siihen: nykyään binääridataa ja tekstiä käsitellään PHP:ssä samalla tietotyypillä.

The Alchemist kirjoitti:

Binäärityypin kanssa on sekin ongelma, että string-int-vertailussa php konvertoi merkkijonon kokonaisluvuksi (...), mutta mikä voisikaan olla tiettyä binäärijonoa vastaava kokonaislukuarvo?

PHP-loogisesti vaikka ensimmäiset tavut natiivin arkkitehtuurin mukaan luettuna. 8)

Moniko muistaa (tai edes tietää), että PHP:ssä voi tehdä tiettyjä bittioperaatioita merkkijonoille? Kätevästi onnistuu mm. xor-kryptaus.

<?php
function xor_crypt($str, $key) {
	$out = "";
	for ($i = 0; $i < strlen($str); $i += strlen($key)) {
		$out .= substr($str, $i, strlen($key)) ^ $key;
	}
	return $out;
}
echo xor_crypt("abcdefg", "\x20\x30"), "\n"; // ARCTEVG
echo xor_crypt("ARCTEVG", "\x20\x30"), "\n"; // abcdefg

Metabolix kirjoitti:

Tietenkin aina voi kehitellä tilanteita, joissa koodi toimii väärin, mutta keksipä nyt jokin järkevä todellinen tilanne, jossa teksti pitää katkaista explodella e-kirjainten kohdalta ja perässä saattaa olla combining diacritic. Näytä sitten vielä jokin kieli, jonka natiivi Unicode-tuki käsittelee tuon tilanteen oikein: yleensä koodeissa käsitellään koodipisteitä eikä näkyviä merkkejä, joten saat luultavasti väärän tuloksen suurimmalla osalla kielistä (mm. Pythonilla).

Otetaanpa .NET:

string s = "åäöe\u0308sadf";
Console.WriteLine(s);
Console.WriteLine(s.Length);
Console.WriteLine(s.IndexOf("e"));
Console.WriteLine(s.IndexOf("ë"));

Konsoliin tulee (koska ei tue Unicodea):
åäöe"sadf
9
-1
3

Ymmärtää siis että e+diakriitti on sama kuin ë, mutta silti kertoo tuossa olevan 9 merkkiä ja tulostaa 9 merkkiä. Mutta jännästi itse asiassa String.Split() ei toimi oikein. Se tunnistaa e:n, mutta ei ë:tä. Ei siis täydellinen jos puhutaan splittailusta. Miksiköhän noin...

Pythonista, Javasta tai muista en osaa sanoa miten toimivat.

Ja toki tuo ei välttämättä ole kauhean yleistä, mutta en kuluttanut oikeasti paljoa aikaa esimerkin keksimiseen. Noita tilanteita kuitenkin on. Joissain kielissä voi jopa merkitys muuttua. Esimerkiksi liettuassa on aika iso ero onko e vai ė vai ę ja jos vaikkapa tuo ogonek/nosinė on esitetty erillisenä koodina, voi haut tai muut operaatiot tuottaa ihan vääränlaisia tuloksia jos sitä ei osata käsitellä oikein. Joskus voi olla hyödyllistä tallentaa merkit erillisinä.

Joka tapauksessa en lähtisi leikkimään Unicode-teksteillä missään formaatissa ilman Unicode-funktioita, vaikka kuinka rajoitetusti niitä voisikin käyttää.

CharUnicodeInfo Class