Arch Linux přešel na PHP 7.0

Před měsícem byla vydána verze 7.0 skriptovacího jazyka PHP (zprávička). Vývojář Arch Linuxu Pierre Schmitz informuje, že balíčky s PHP 7.0 se dostaly do stabilních repozitářů Arch Linuxu (php).

3.1.2016 10:37 | Ladislav Hagara | Komunita

Komentáře

[Odin1918]

Dalsi verze bude devet, nebo rovnou deset?

[Kozzi]

Rekl bych ze 7+1 = 8. Takze dalsi major verze bude php 8

[Kozzi]

Samozrejme je tu stale riziko ze dalsi verze nevyjde :)

[Odin1918]

Sestka byla prece preskocema

[kozzi]

Tak nebyla, ono PHP 6 existovalo, jen se nikdy nevydalo :) viz. : http://www.wrox.com/WileyCDA/WroxTitle/Professional-PHP6.productCd-0470395095.html

[Nobody]

Dalsi verze bude 47, aby to bylo vic Chrome.

[Odin1918]

Dnes je asi takova moda. Dokonce i kernel zvysuje inkrementacni tempo.

[Petr Mika]

Historical context

The reason why this question even comes up, is that there has been a previous attempt at a new major version, which was started in 2005 and abandoned in 2010 due to difficulties in the Unicode implementation. Apart from language-integrated Unicode support, most features added for that version were integrated either in PHP 5.3 or PHP 5.4.

This previous attempt at a new major version was also developed under the name of PHP 6 and as such there are various resources referring to it, including a number of books. There is concern that there might be confusion between the abandoned previous attempt and the work that is currently happening.

[Odin1918]

Jiste. Toto vim. Dokonce si i pamatuji, jak se hlasovalo, zda se ma sestka preskocit. Ja s tim preskocenim silne nesouhlasim, proto jsem si musel rypnout.

[kralyk z abclinuxu]

Vždyť je to jen číslo...

[slayer]

Tato zprávička je o dostupnosti balíčků PHP 7 pro Arch Linux

Dále viz. zde: https://cs.wikipedia.org/wiki/Troll_(internet)

Captain Obvious OUT

[kralyk z abclinuxu]

Jsem tak nadšen, že na to asi zareaguju něčím jako

pacman -Rcs php
pacman -S python-flask

[kyknos]

takze uz je zase PHP o mili pred Perlem

[mmmmario]

Už to umí UNICODE?

[JoHnY]

Roky, ale ne tak jak to myslis. Umi C Unicode?

PHP nema komplexní string jako Java, C#, Python3 nebo Ruby. V PHP je string variabilni byte-string, ktery na rozdil od C smi obsahovat NUL. Co si do nej programotor ulozi a jak s nim bude zachazet je jeho problem.

[kyknos]

takze neumi

[Jendа]

Příklad?

(nevím, v PHP pracuju se stringy v UTF-8 a ještě jsem žádný problém nepotkal)

[mirec]

php > $x = 'č';
php > echo $x[0];
Ä

[slayer]

Ve smyslu toho na co se snažíte poukázat, je Váš příklad chybný. Namísto prvního znaku používáte první byte a tím se snažíte dokázat, že PHP nedokáže získat znak na dané pozici unicode řetězce.

String je v PHP binární řetězec.

Pokud chcete získat první znak, pak je správný příklad zde:

php > $x = 'č';
php > echo mb_substr($x, 0, 1);
č

[mirec]

php > $x = 'c';
php > $x[0] = 'č';
php > echo $x;
Ä

Žiadne varovanie, veď prečo by aj keď na miesto 1 byte sa snažím vložiť 2 byte, že.

[slayer]

Dalo by se souhlasit s tím, že alespoň warning by to mohlo vyhodit, nicméně stejně jako předchozí příklad, ani tento nemá nic společného s podporou unicode:

php > $x = 'c';
php > $x[0] = 'XXX';
php > echo $x;
X

Opět odkazujete na jeden konkrétní byte a jako vstup mu předáváte více bajtů - do jednoho bajtu se (jak známo) vejde právě jeden byte - zbytek řetězce je ignorován.

Explicitní kontrola zda je v tomto případě řetězec delší než 1 byte a následné vyvolání warningu je trochu diskutabilní - např. z hlediska výkonu (proč se starat o zbytek když plníte právě jeden bajt).

Pokud chcete znak na konkrétní pozici nahradit jiným znakem, musíte (opět) použít funkce pro zpracování textových, nikoliv binárních řetězců.

Mmch. v tomto případě je to trochu podobné např. v Javě - Stringy tam jsou totiž immutable a také nemůžete změnit znak, ale musíte si to explicitně zpracovat a vyrobit nový String.

[mirec]

In [1]: x = 'č'

In [2]: x[0]
Out[2]: 'č'

In [3]: len(x)
Out[3]: 1

Môžme prehlásiť, že podpora unicode v PHP je rovnaká ako podpora unicode v assembleri, alebo C.

[kyknos]

tak on jakykoliv turingovsky kompletni jazyk "podporuje" unicode, ze

[slayer]

Prohlásit to můžete třeba 1000krát, ale pravdu tím z této nepravdy neuděláte. PHP podporuje multi-byte řetězce nativně již řadu let.

http://php.net/manual/en/ref.mbstring.php http://php.net/manual/en/book.mbstring.php

Značná část těchto funkcí je v PHP od verze 4.0.6 - vydané v červnu 2001

Skutečnost, že se stále dokola snažíte poukazovat na údajnou nepodporu unicode pomocí používání operací pro binární řetězce a vyhýbáte se (záměrně?) používání funkcí k tomu určených, Vás bohužel efektivně posouvá do role (omlouvám se) neznalce či trolla.

[_]

Asi si pod slovem podpora představuje trošku něco jiného. Já také.

[mirec]

V assembleri nemám problém nastaviť do registrov (alebo na stack podľa konvencie volania) adresu reťazca v pamäti, index znaku a adresu znaku pre nahradenie a spustiť subrutinu, ktorá vykoná nahradenie unicode znaku. A presne na takej úrovni je podpora unicode v PHP. V assembleri musím myslieť na to, že je to kus pamäte rovnako ako v PHP. V assembleri musím použiť subrutinu pre manipuláciu s unicode rovnako ako v PHP musím použiť funkciu pre manipuláciu s unicode. Ak to v jednom či druhom jazyku neurobím skončím s nesprávnym reťazcom.

Podpora unicode sa dá dopísať do ľubovoľného turing complete jazyka, ale za skutočnú podporu unicode považujem keď mi jazyk dovolí nemyslieť na to, či pracujem s unicode, alebo nejakými inými dátami.

[slayer]

To co jste právě popsal je situace kdy vlastně žádný vyšší jazyk podporu Unicode nemá, protože naprosto všechny vyšší jazyky dělají přesně to co jste popsal a Unicode tím de-facto neexistuje, protože se jedná jen o bajty a bajty, které se někde nějak počítají a nahrazují atd. atd.

Tímto se, prosím, považujte za přemoženého trolla a zkuste to příště, třeba Vás nikdo tak snadno neprohlédne

[mirec]

Python, Js, Perl ... u všetkých týchto jazykov sa nemanipuluje priamo nad bytmi, nedá sa omylom rozbiť unicode reťazec. U PHP, C, Assembleru ... je naopak nutné dávať pozor na to, či probramátor pracuje s unicode, alebo so surovým kusom pamäte.

[Jendа]

U PHP, C, Assembleru ... je naopak nutné dávať pozor na to, či probramátor pracuje s unicode, alebo so surovým kusom pamäte.

U Pythonu taky, spousta funkcí teď vrací takové ty divné binární/buffer stringy, a pak mě vždycky strašně naštve, když to hodí během rozdělané práce exception že ho to nemůže nacpat do dekódovaného stringu.

[mirec]

Aspoň, že niečo vyhodí. Nie až tak dávno som prepísal linuxos.sk do pythonu pretože som tam mal príliš veľa neošetrených chýb nie len s unicode (viem je to jeden z mojich prvých PHP projektov a úplne prvý python projekt).

[slayer]

Mícháte jablka s hruškami - práce s textem vs. práce s binárními daty.

To že vám PHP umožňuje pracovat se Stringem za pomoci jednotlivých bajtů je možnost, nikoliv nutnost. Pokud chcete pracovat binárními funkcemi, ale prosím, můžete, ale nemůžete to pak dávat do souvislosti s podporou unicode.

PHP Vám dává možnost přistupovat ke Stringu 2 odlišnými způsoby a je na Vás, který si zvolíte - podle toho, co potřebujete docílit.

Drobná ukázka:

Chcete znát počet textových znaků v řetězci?: PHP: použijete mb_strlen() Java: použijete String.length()

Chcete znát počet bajtů, které String zabírá v daném kódování? PHP: strlen() Java: String.getBytes("UTF-8").length

rozdíl: PHP Vám k bajtům dá přístup přímo, Java Vám dá, namísto přímého přístupu, kopii v podobě pole bajtů, kterou si můžete upravit a poté zase převést na String

Pohodlnost hrabání se v unicode Stringu pomoci binárních funkcí/metod je podobně ujetá v obou případech a stejně jako si v PHP do jednoho konkrétního bajtu nezapíšete vícebajtový řetězec, tak ani v Javě si na daný bajt nezapíšete delší řetězec v naději, že se snad další bajty sami posunou.

Je to rozdílný přístup, netvrdím že je správný lepší nebo zářivější, je prostě jiný. A absolutně nic to nemění na tom že PHP podporu unicode má. Brblejte si jak chcete, porovnávejte si jak chcete, je tam a je tam už 14 let

[mirec]

Mícháte jablka s hruškami - práce s textem vs. práce s binárními daty.

Tak prečo PHP mieša prácu s textom s binárnymi dátami?

To že vám PHP umožňuje pracovat se Stringem za pomoci jednotlivých bajtů je možnost, nikoliv nutnost.

Mnou spomenuté jazyky neumožňujú pracovať so stringom pomocou bytov. To je dosť podstatný rozdiel.

[slayer]

Tu práci ale nemíchá PHP, tu práci mícháte VY.

Ano, PHP je typově dost slabé.

Ano, PHP Vám umožní volat konstrukce, které by jinde neprošli.

Má toto něco společného s reálnou podporou unicode? NE

[Jendа]

Takže jediný problém je v tom, že lze udělat str[i]?

[mirec]

Problémov bolo viacej od substr, ktoré umožňovalo robiť všeličo od XSS po SQL injection ak sa reťazec sekol v nesprávnej časti znaku, mysql_escape_string namiesto mysql_real_escape_string, ereg namiesto preg, mnoho mnoho unsafe záležitostí jednoducho spočítané a podčiarknuté oplatilo sa mi viacej naučiť sa nový jazyk, nový framework a celé to napísať odznovu než opravovať chybný kód.

[slayer]

Takže abych shrnul Váš názor na PHP vs. podpora Unicode:

Měl jste (ať už vlastní či cizí) kód, který míchal unicode řetězce s binárními funkcemi a podle toho odvozujete, že PHP nemá podporu Unicode.

To je přímo brilantní

[mirec]

Ešte raz PHP umožňuje manipulovať unicode reťazcami nepovoleným spôsobom.

Podpora unicode v PHP sa nelíši od podpory unicode v asm.

[slayer]

Ještě jednou:

To že to umožňuje provést, neznamená, že to tak máte používat a pak si stěžovat na (ne)podporu.

Podpora Unicode se v PHP od asm liší řádově - Zatímco PHP Vám dává plnou náruč nativních funkcí pro práci s textem - máte je k dispozici 14+ let ať chcete nebo nechcete, zatímco asm Vám žádné takové nativní funkce nedává, musíte si je sám napsat.

[kralyk z abclinuxu]

máte je k dispozici 14+ let ať chcete nebo nechcete, zatímco asm Vám žádné takové nativní funkce nedává, musíte si je sám napsat.

Nebo použiješ v asm existující C knihovnu, což je přesně ten přístup PHP - mb_string je nejspíš pouze nějaký tenký wrapper nad C knihovnou, žádné abstrakce navíc PHP neposkytuje, je to úplně ten stejný suchý záchod jako v asm.

[slayer]

Jistě ... nebo si to celé implementuješ sám což je zase přístup jiných jazyků

V tom případě se můžeme začít dohadovat nad přesnou definicí toho co znamená "Podpora Unicode" :)

Dle mého názoru podpora Unicode v daném jazyce znamená bezprostřední (žádné extra nahrávání) možnost provádět operace s textem, aniž bych musel přemýšlet nad kódováním a dekódováním, vyrábět nebo explicitně načítat nějaké mapy znaků, počítadla, convertory apod.

Podle kolegy mirce se však zdálo, že i v případě nativní existence všech potřebných funkcí/metod podpora Unicode přestává existovat ve chvíli, kdy ti jazyk zároveň umožňuje provést zásah do binární reprezentace daného řetězce, což je, dle mého názoru nesmysl.

[kralyk z abclinuxu]

V tom případě se můžeme začít dohadovat nad přesnou definicí toho co znamená "Podpora Unicode" :)

Jsem pro "má datový typ pro unicode stringy". To totiž PHP, C, asm, etc. nemají...

[mirec]

Natívny v zmysle preložený do strojového kódu je aj v asm.

Len tak pre zaujímavosť nedávno som robil štatistiku prechodov zo znaku a na znak b v slovenskom texte aby som podľa neho zostrojil generátor pseudoslovenského textu. Skúste si v PHP so mb_* funkciami napísať program, ktorý z textu vypíše početnosť prechodov z predchádzajúceho na nasledujúci znak. V pythone je to:

from __future__ import unicode_literals
from collections import Counter
s = "ááááách"
Counter(zip('\0' + s, s + '\0')).most_common()

A výstup:

[(('á', 'á'), 4),
 (('c', 'h'), 1),
 (('h', '\x00'), 1),
 (('á', 'c'), 1),
 (('\x00', 'á'), 1)]

Vďaka natívnej podpore unicode žiadne rozmýšľanie nad reprezentáciou reťazca (u pythonu3 sú unicode literaly default).

[slayer]

OK tak tedy zde je PHP verze: (mírně odlišné chování co se týká začátku a konce řetězce je způsobené odlišnou konstrukcí klíče v mapě ve vašem a mém skriptu)

$s = "ááááách";

$map = array();

for ($i = 0; $i < mb_strlen($s); $i++) {
    $k = mb_substr($s, $i, 1) . mb_substr($s, $i+1, 1);
    if (!array_key_exists($k, $map)) $map[$k] = 0;
    $map[$k]++;
}

Výstup:

Array
(
    [áá] => 4
    [ác] => 1
    [ch] => 1
    [h] => 1
)

... Díky podpoře unicode žádné rozmýšlení nad reprezentací řetězce ...

[slayer]

Případně ještě zkrácená verze: (zavináč před $map je pro potlačení warningu při prvním odkazu na neexistující $map a zároveň na první neexistenci daného klíče v poli)

$s = "ááááách";

for ($i = 0; $i < mb_strlen($s); $i++) @$map[mb_substr($s, $i, 2)]++;

[mirec]

To má zložitosť O(n²). Na dlhé texty nič moc.

[nope]

1. pokud myslíte složitost v rámci jazyka tak nikoliv, počet kroků je lineární k délce řetězce - provádí právě tolik iterací, kolik je v řetezci znaků a menší počet kroků v tomto případě není možný už jen z té logiky, že se snažíte udělat statistiku všech po sobě jdoucích přechodů

2. jinou otázkou je složitost skrytá za horizontem - odhaduji, že funkce mb_substr() bude pravděpodobně při každém volání parsovat celý řetězec na unicode znaky dokud nebube schopna poskytnout výsledek - Např. vzhledem k nepevné délce znaků UTF-8 je toto věc, kterou musí řešit všechny jazyky, leda by si řetězec vnitřně implementovali jako pole jednotlivých znaků, čímž by zároveň umožnili jeho indexovatelnost, případně při jeho zadávání detekovali vstupní kódování, poté překódovávali na unicode s pevnou šířkou znaku (UTF-32) a to samé nazpět při každé operaci, nebo by striktně určili že každý řetězec je jen a pouze např. zmíněné UTF-32

3. nic z výše popsaného neznamená, že jazyk php nemá podporu unicode

chápu, právě vám někdo po milionté dokázal, že se mýlíte ve svém názoru na údajnou nepodporu unicode v php, takže přepínáte na troll mode a odbíháte od tématu který jste sám začal a snažíte se řešit <|> kolem

[kralyk z abclinuxu]

Troll mode tady bude mít někdo jinej než mirec. Dovolím si citaci:

A string is series of characters, where a character is the same as a byte. This means that PHP only supports a 256-character set, and hence does not offer native Unicode support.

[zdroj]

Dovolím si zvýraznit jistou část:

A string is series of characters, where a character is the same as a byte. This means that PHP only supports a 256-character set, and hence does not offer native Unicode support.

Vzhledem k dosavadní diskusi to asi není dostatečné zvýranznění, takže:

A string is series of characters, where a character is the same as a byte. This means that PHP only supports a 256-character set, and hence

does not offer native Unicode support

Předpokládám, že následně nastane nesmyslná diskuse nad slovy "native support" a o nesmrtelnosti chrousta... Protože akecptovat nedostatek PHP, toho PHP fanbois nejsou fyzicky schopni...

[LOL]

Nikoliv drahý trolle, předpokládáte naprosto špatně, vaše trollení totiž snadno utnu citací původní otázky:

"Už to umí UNICODE?"

a původní odpověďi:

Roky, ale ne tak jak to myslis. Umi C Unicode? PHP nema komplexní string jako Java, C#, Python3 nebo Ruby. V PHP je string variabilni byte-string, ktery na rozdil od C smi obsahovat NUL. Co si do nej programotor ulozi a jak s nim bude zachazet je jeho problem.

Na hloupu otázku byla podána jasná odpověď ... a poté přišel troll

[kralyk z abclinuxu]

No myslím, že PHP manuál má poněkud větší váhu než anonymní koment na abclinuxu, ale i tak díky za cenné informace...

[LOL]

Myslet si pochopitelně můžete co chcete. Faktem je, že odpověď na původní hloupu otázku je zcela v souladu s tím co PHP manuál uvádí.

[Václav "Darm" Novák]

Původní otázka byla možná položena trochu hloupě, ale celé další vlákno zjevně probírá nativní podporu. Pomocí nějakých podpůrných funkcí „umí“ UTF-8 asi každý jazyk.

[kralyk z abclinuxu]

Původní otázka taky zjevně myslela nativní podporu, protože to byla celkem zjevná narážka na PHP6, kde se o nativní podporu pokusili.

[lol]

naopak, zcela zjevně nepadlo o nativní podpoře ani slovo

[mirec]

Takže aby som to zhrnul pre indexovanie so zložitosťou O(1) musím pretypovať na UTF-32. Lenže to je nová zbytočná nekonzistentnosť v mojej aplikácii, takže je fajn prepísať celú webovú aplikáciu do UTF-32 (teda napísať na všetky miesta kde je to nutné konverziu, áno tento skvelý jazyk pri miešaní bytov s unicode nevyhodí výnimku ani varovanie), zdrojové kódy písať v UTF-32 (zvláda PHP zdroják napísaný v UTF-32?), alebo na všetky reťazce použiť konverziu a v šablóne pri každom výpise použiť konverziu. Takže ten jazyk ma vlastne núti zahodiť celú moju aplikáciu ak chcem zostať konzistentný. Tak to je skvelá abstrakcia, ktorú ponúkajú jazyky so skvelou (TM) podporou unicode.

[LOL]

LOL, Java vnitřně používá UTF-16 (2-4 bajty), Python používá vlastní interní formát a pro unicode vstup/výstup provádí konverze.

Takže pokud se oháníš nutností překódovat do UTF-32 pro dosažení konstatní složitosti, tak mám pro tebe překvapení - další jazyky to překódování musí řešit také. Některé jazyky to řeší již při ukládání, některé až při zpracování. Tvoje argumenty jsou zcela mimo mísu.

Buď tak laskav a než příště začneš kydat podobné perly jako tu výše, přečti si o unicode a jeho zpracování v různých jazycích alespoň pár stránek.

[mirec]

Konzistencia Vašich názorov je niekde na úrovni pohotovostného sáčku na grcanie ktorý som kedysi vymyslel na internáte.

Díky podpoře unicode žádné rozmýšlení nad reprezentací řetězce ...

... detekovali vstupní kódování, poté překódovávali na unicode s pevnou šířkou znaku (UTF-32) a to samé nazpět při každé operaci, nebo by striktně určili že každý řetězec je jen a pouze např. zmíněné UTF-32

Takže buď musím ručne prekódovať v časti mojej aplikácie a potom musím používať mb_substr(..., 'utf-32') v časti kde používam UTF-32 a mb_substr(..., ['utf-8']) v časti kde používam UTF-8 a teda musím sa nutne zamýšľať nad aktuálnou reprezentáciou textu v časti aplikácie kde sa práve nachádzam (keďže som v tomto nekonzistentný a niekde používam UTF-8 a inde UTF-32), alebo musím nutne prepísať celú aplikáciu tak, aby interne používala UTF-32 a to je presne to, čo som napísal.

Mimochodom v mojom príklade vôbec indexáciu nepotrebujem, stačí mi iterácia všetkými prvkami so zložitosťou O(n) čo zvláda mimochodom bez problémov aj ICU (U8_NEXT) v C.

Inak vlastnú reprezentáciu používa PERL (či skôr rozšírenie NFC formy UTF-32 o rozsah 0x80000000-0xFFFFFFFF + tabuľka grafemov). Python používa podľa nastavení pri kompilácii buť UTF-16 alebo UTF-32.

[Lol Phirae]

Zhodnocení tvých mouder:

💩💩💩

[lol]

Naopak, konzistence mých názorů je stejná, to VY naopak zcela odbíháte od tématu a snažíte se chytat kdejakého rádoby-stébla, měníte předmět diskuse jakmile zjistíte že na dané téma již nemáte naprosto žádné argumenty.

Nejprve naprosto zcestně používáte binární operace nad unicode řetězcem a snažíte se přitom tvrdit že to tak má být správně protože je to tak implementované v jiném jazyce (kdyby to bylo implementované stejně, nebyl by to jiný jazyk ...) poté začnete argumentovat složitostí algoritmu která nemá s podporou unicode nic společného a vršíte jeden nesmysl na druhý.

Mimochodom v mojom príklade vôbec indexáciu nepotrebujem, stačí mi iterácia všetkými prvkami so zložitosťou O(n) čo zvláda mimochodom bez problémov aj ICU (U8_NEXT) v C.

... ale ano potřebujete, jen dokola odmítáte pochopit, že ta indexace probíhá skrytě zatímco můj příklad ji otevřeně přiznává. S vaší logikou by pak stačilo, abych si ten jednořádkový skriptík zabalil do funkce a mohu tvrdit to samé co vy - zavolám funkci/metodu jako v uvedeném python skriptu a budu vesele tvrdit, že žádná konverze/indexace neexistuje Tu indexaci/konverzi kterou vy odmítáte vidět totiž provádí daný jazyk vnitřně a při každé vstupní a výstupní textové operaci. Uvědomte si už konečně, že jakékoliv unicode které nemá pevný počet bajtů na jeden textový znak je nutné při podobných operacích parsovat ať už vnitřně, nebo explicitně. Pokud vám jde o výkon tak v jednom jazyce si to prostě nejdříve převedete explicitně zatímco druhý vám to převede transparentně, pokud vám jde o výkon tak v obou případech můžete dosáhnout stejné složitosti.

Php a Python pracují se stringy odlišně to je prostě fakt a ten byl řečen již na začátku. Vaše argumentační omyly a veletoče nemění nic na tom že php podporu unicode má, můžete se třeba 100x postavit na hlavu. To že daný specifický úkol může být (bez explicitní optimalizace) výpočetně efektivnější v jiném jazyce na tom nic nemění, php unicode podporuje i kdybyste jste se milionkrát snažil dokázat opak.

[kralyk z abclinuxu]

Vaše argumentační omyly a veletoče nemění nic na tom že php podporu unicode má, můžete se třeba 100x postavit na hlavu.

Jasnýýýý, že má A o co šlo podle tebe v PHP6? Předpokládám, že to bylo něco jako "změna charakteru podpory Unicode na mírně jinou - pozor, nikoli lepší, to v žádném případě!", že?

[kralyk z abclinuxu]

ale ano potřebujete, jen dokola odmítáte pochopit, že ta indexace probíhá skrytě zatímco můj příklad ji otevřeně přiznává

Mimochodem, toto není pravda. Mirecův příklad používá iterátor, v tom je ten rozdíl.

[mirec]

Hlboko sa ospravedlňujem, nikdy by som si nedovolil rýpať do človeka, ktorý trpí dyslexiou za to, že nepochopil komentár.

Aby ste nemuseli prechádzať celým vláknom tak to zhrniem do 2 viet.

PHP má podporu unicode na rovnakej úrovne ako jazyky 1. a 2. generácie (asm/C). Jazyky 3 generácie a vyššie už zvyčajne majú samostatný dátový typ pre unicode, na ktorom nie je možné omylom seknúť znak v polovici.

indexace probíhá skrytě zatímco můj příklad ji otevřeně přiznává

Iterácia nevyžaduje indexáciu. Môžem prejsť celý utf-8 reťazec po znakoch (v každom kroku prečítam jeden znak a posuniem ukazovateľ na začiatok ďalšieho) a budem mať zložitosť O(n) a nie O(n²).

[kralyk z abclinuxu]

Jazyky 3 generácie a vyššie už zvyčajne majú samostatný dátový typ pre unicode, na ktorom nie je možné omylom seknúť znak v polovici.

Abychom byli k tomu chudákovi zmatenému trochu fér, tak je nutno dodat, že nevalidní utf-8 stringy jsou bohužel možné i v některých vyšších jazycích např. python a JS. JS navíc AFAIK ani pořádně nenabízí možnost utf-8 validovat. V pythonu je podpora na mnohem lepší úrovni - datový typ, možnost validace, iterátory, apod. Imho nejlépe je na tom Rust, kde ani nedovolí nevalidní utf-8 string zkonstruovat.

[Václav "Darm" Novák]

(kdyby to bylo implementované stejně, nebyl by to jiný jazyk ...)

Zvláštní logika. Když jazyk b implementuje jednu věc tak jako jazyk a, přestává být samostatným jazykem? Ale je fakt že vyřešením všech problémů PHP by to už zákonitě přestalo být PHP a začalo být jiným jazykem který má nějaký ucelený koncept a konzistenci místo „dortu pejska a kočičky“.

[lol]

Je to použití stejné logiky, jakou používá mirec, dle něj je totiž konstrukce $s[0] vracející byte na dané pozici chyba, která znamená že daný jazyk nepodporuje unicode - protože on chce aby tato konstrukce vracela unicode znak na dané pozici v textu, protože tak to funguje v jiném jazyce, který on preferuje

[mirec]

Funkcie / subrutiny pre prácu s unicode majú jazyky 1. a 2. generácie. Jazyky 3. generácie majú zvyčajne dátový typ unicode, ktorý nedovolí náhodnú manipuláciu bytmi. Keď to intrpretujete ako "daný jazyk nepodporuje unicode" je to Váš problém.

konstrukce $s[0] vracející byte na dané pozici

Konštrukcia $s[0] vracia 0-položku sekvencie.

[Václav "Darm" Novák]

U jazyku s rozumnou podporou unicode očekávám, že obecná funkce pro práci s řetězci bude vracet předpokládatelné hodnoty. Pokud je nevrací, není to podpora unicode. V jazyku který unicode neumí si taky můžu přibalit knihovnu která to nějak zvládne. Ostatně, v praxi se teď setkávám s nutností roubovat unicode do CP1250. Funkce se budou nazývat jinak (jako v PHP, to že ty knihovny jsou ve standardním balíku funkcí je sice hezké, ale nic moc to nemění).

Opět, jak již bylo řečeno, v assembleru takhle podporovat unicode dovedu taky. Jazyk ovšem s unicode defaultně nepočítá a potřebuje berličky.

[Bedňa]

Táto debata mala pôvodne trochu iný smer a keby sa toto objasnilo na začiatku, tak by sa do nej väčšina ani nezapojila.

Z pohľadu PHP je string bajtový blob. Viedli sa o zmene diskusie, ale nakoniec sa uznalo že to tak ostane kvôli výkonu. Do stringu v PHP nacpeš proste obrázok, muziku a hocičo iné, je to webovo orientovaný jazyk.

Z pohľadu UNICODE ULTRAS je jediná správna cesta aby štandartné funkcie vracali znak a nie bajt.

PHP má na to spravenú barličku MB, ktorá to rieši v jazyku, bez frameworku, či to je správne, alebo nie je zas na inú debatu.

Pointa je, že sa to tu zamotalo a zbytočne to prerástlo do nejakých osobných sporov, čo je blbosť. Však sa máme radi :)

[lol]

Nemáme. Mirec je zmrd.

[Bedňa]

Mirec, ale kto použije bitovú operáciu nad unicode je prasa, teda pokiaľ to nerobí z nejakého dôvodu zámerne.

V PHP sa dá prasiť asi viac ako v iných jazykoch, ale to je predsa vždy na programátorovi, nie jazyku.

[mirec]

To vysvetli všetkým tým, ktorí v tutoriáloch používali substr namiesto mb_substr. Keď som začínal vedel som o jazyku veľké prd. Až neskôr som zistil, že za určitých okolností mi substr sekne reťazec v polovici znaku, občas tak nešťastne, že keď sa v html ako nasledujúci znak nachádzal < tak to rozbilo layout HTML. Ak sa také niečo vyskytlo v generovanom js bol z toho XSS ako vyšitý.

[Bedňa]

Nespomenúť pri práci s reťazcami MB reťazce je samozrejme chyba.

Kopu zlých návykov nájdeš v tútoriáloch pre každý jazyk. Však koľko projektov je podnes problém portovať na 64bit architektúru a príkladov by sa určite našlo viac.

[Jendа]

To vysvetli všetkým tým, ktorí v tutoriáloch používali substr namiesto mb_substr.

Špatné tutoriály nejsou problém PHP, stejně jako nebude problém Pythonu, když na něj napíšu tutoriál (špatný, protože neumím programovat).

[Jendа]

Ešte raz PHP umožňuje manipulovať unicode reťazcami nepovoleným spôsobom.

Python taky.

Ergo Python nepodporuje Unicode.

[kyknos]

V pythonu si clovek takhle nerozbije drzku. Je to intuitivni a pohodlne. V php presne naopak.

[Jendа]

Já si na kódování stringů rozbíjím držku v Pythonu (3) i v PHP (teď přemýšlím, kde všude jsem použil substr).

[kyknos]

Ja tedy ne, akorat obcas jsem srozumitelne informovan, ze nekam cpu bajty, kde potrebuju string

[Jendа]

substr

https://secure.php.net/manual/en/function.mb-substr.php

mysql_escape_string namiesto mysql_real_escape_string

Toto bylo od začátku rozbité a proto je v PHP už sto let normální databázový interface s parametrizovanými dotazy.

[kralyk z abclinuxu]

PHP Vám dává možnost přistupovat ke Stringu 2 odlišnými způsoby a je na Vás, který si zvolíte - podle toho, co potřebujete docílit.

Ano, PHP dává možnost, jenže to API je, jako téměř vždy u PHP, nelogické a matoucí. mb_strlen($string) je jistě funkční, ale naprosto neintuitivní. $srting->length by bylo mnohem lepší, jenže to by PHP muselo podporovat scalar objects...

[slayer]

Aha, takže z jedné off-topic debaty (balíčky pro Arch vs. údajná nepodpora Unicode v PHP) teď začne někdo další flamovat nad PHP vs. jiné jazyky?

Kolego, jeden mýtus jsme právě vyvrátili, nezačínejte prosím zbytečný flame o rozdílech mezi jazyky jen proto, že zrovna PHP je o dost volnější než jiné, kdyby všechny jazyky uměly všechno a stejně, stačil by všem jeden a ne různé jazyky s různým určením a možnostmi ...

PHP je odlišné od jiných jazyků a jiné jazyky jsou odlišné od dalších jiných jazyků ... Berte nebo nechte, nic to nemění na tom že PHP podporu Unicode má a má ji už dlouho.

[trekker.dk]

Aha, takže z jedné off-topic debaty (balíčky pro Arch vs. údajná nepodpora Unicode v PHP) teď začne někdo další flamovat nad PHP vs. jiné jazyky?

To už je tady trochu folklór, téměř každá zprávička o PHP má v diskuzi "debatu" o tom, jak je PHP špatný jazyk.

[kyknos]

protoze to je extremne spatny jazyk?

[slayer]

protože jste extrémní flamer

[Jendа]

Je.

Ale když se zeptám na náhradu, tak dostanu odpověď „napiš si do tohoto šablonovacího systému podporu pro proudové zpracování“ nebo „napiš si do této knihovny podporu pro fcgi/http“.

[trekker.dk]

A co teprve, kdyby se náhodou někdo zeptal, čím má nahradit svůj web, který mu běží na Wordpressu, a kde k tomu sežene hosting.

[kralyk z abclinuxu]

Já jsem se v jedné z posledních zpráviček o PHP zeptal na podobnou otázku a poradili mi (myslimže to byl Darm) OpenShift a Heroku, které podporují řadu server-side technologií. Přijde mi to dobrý a cyhstám se v brzké době jednu původně PHP aplikaci přemigrovat na Openshift.

[Václav "Darm" Novák]

Jojo, byl jsem to já :) Chce to obětovat chvilku času k nastudování adresářové struktury a funkce deploy skriptů, ale IMO to za to stojí.

[trekker.dk]

Ok, to by byl hosting, co ten Wordpress? Připomínám, že průměrný uživatel Wordpressu jej používá proto, že je to jednoduché na instalaci, zadarmo ke stažení a obsah si tam nakliká sám.

[kralyk z abclinuxu]

Já řešil svou aplikaci. Co se týče CMS, znám jen Wordpress a Jekyll, s tím prvním mám špatné zkušenosti, s tím druhým velmi dobré. Takže asi nutno se po něčem poohlédnout.

[trekker.dk]

Jo, mimo PHP nic moc výběr a spousta položek v tom seznamu má poslední verzi rok a víc starou, tj. nevyvíjí se to. Možná by bylo zajímavé porovnat ještě funkcionalitu, ale do toho se mi nechce (nehledě na to, že výsledek by pravděpodobně nepřekvapil...)

[kralyk z abclinuxu]

Co třeba Mezzanine?

[Jendа]

A nepřeberné množství pluginů a vzhledů…

[Václav "Darm" Novák]

Založím účet na openshift a místo obecné cartridge PHP nahraju obecnou cartridge Wordpress.

[trekker.dk]

Super, akorát tady zase chybí nahrazení PHP něčím jiným

[Václav "Darm" Novák]

Na stranu druhou, většině lidí co si potřebujou nastavit web ve wordpressu je jazyk celkem putna… A ti kterým není si tam nahodí jiný CMS :)

[kralyk z abclinuxu]

Tohle asi moc nemá cenu. I kdyby PHP pro délku Unicode stringu mělo funkci jménem bflmpsvz(), která by vracela 3*délku stringu + 5, tak se najdou lidi, kteří budou tvrdit, jak je to naprosto v pořádku a jak je to plnohodnotná podpora Unicode...

[mirec]

To mi pripomenulo funkciu gzgetss :D

[Bedňa]

Alternatíva k zcat, v PHP je celkovo dosť z Linux enviroment, hoci túto som nepoznal.

[Bedňa]

Ktorá z týchto funkcií vracia nejaké násobky +5? Alebo ktorá vracia niečo iné ako má? Ak to tak nieje toto sú len výkriky do tmy.

[kralyk z abclinuxu]

To co jste právě popsal je situace kdy vlastně žádný vyšší jazyk podporu Unicode nemá

To není pravda.

Viz třeba tady nebo tady.

[Jendа]

Jako že u PHP tě štve, že str[1] vrátí nesmysl, a musíš na to používat extra funkci, a jako příklad něčeho lepšího dáš jazyk, kde str[1] vůbec nefunguje, a musíš na to používat extra funkci?

Because strings are valid UTF-8, strings do not support indexing:

let s = "hello";

println!("The first letter of s is {}", s[0]); // ERROR!!!

Usually, access to a vector with [] is very fast.

[kralyk z abclinuxu]

Mně to přijde jako správné řešení. U toho JS je vzhledem k povaze + zaměření toho jazyka celkem na místě, že neřeší tolik výkonnostní stránku. U Rustu naopak očekávám dobrou odhadnutelnost výkonu. Četl jsi to zdůvodnění? Imho dává smysl. Pokud potřebuješ přístup k bajtům, použiješ foo_string.as_bytes() a na to už se samozřejmě indexovací operátor použít dá. Je tím důsledně a jasně odděleno, kdy pracuješ s bajty a kdy s Unicode stringem.

Jde o to, že to rozhraní není matoucí. Narozdíl od PHP, které má pouze ekvivalent toho byte vectoru a ten string vůbec nemá, respektive emuluje ho tím bytevectorem + kupou haluzně pojmenovaných funkcí.

[Bedňa]

To je len rozdielny prístup.

Čo je na tebou vyššie použitom príkaze mb_strlen() matúce?

[mirec]

To, že ako prvé napadne človeka strlen (podľa názvu by mala vracať dĺžku reťazca no v skutočnosti vracia počet bytov). Správne by sa mala volať byteslen a mb_strlen by naopak mala byť strlen ak už chceme niečo čo nie je mätúce.

[Bedňa]

Sem tam robím skripty v Bashi a oproti tomu mi PHP príde ako prechádzka rúžovou záhradou To potom môžeš nadávať aj na rôzne databázové jazyky, proste buď sa s tým zmieriš, alebo v tom písať nebudeš.

[Václav "Darm" Novák]

je fakt že v tom pojmenování standardních funkcí je PHP strašně nekonzistentní a nepředvídatelné. Osobně bych taky předpokládal že strlen vrací přesně dle názvu délku stringu. Už si dovedu představit to hledání chyby :)

(když už mluvíš o DB jazycích, ABL má length(variable, type), kdy type je defaultně počet znaků (characters) a dá se přepnout na byte)

[kralyk z abclinuxu]

No tak jestliže ta podpora Unicode byla tak v pohodě, jak tady někteří tvrdí, tak o co šlo v PHP6, že

[Bedňa]

Jazyk čo má pri definícií premennej NO-UNDO by som nevyťahoval :)

Ja is myslím, že každý jazyk má svoje (P)perly.

[Václav "Darm" Novák]

To je na stranu druhou věc návrhu jazyka (a principu funkce „proměnných“, přičemž pokud no-undo nespecifikuješ, hlavní dopad to má na overhead (dobře, pokud vrátíš transakci, tak i s v daném bloku přiřazenýma hodnotama proměnných, což je ve většině případů celkem jedno, vyjímečně se to i může hodit.) To už bych se spíš pozastavil nad funkcí time, která poměrně nezvykle vrací počet vteřin od půlnoci daného dne :)

Na stranu druhou, ten jazyk je konzistentní… U PHP mě vždycky štvalo už jen to, že nedrží ani jeden styl pojmenování standardních funkcí (občas je název dohromady, občas dělen podtržítkem, konverzní funkce používají občas 2, občas to) , natožpak pořadí parametrů (namátkou array_key_exists, property_exists) A teď si to pamatuj… Jo, jde to, ale je to další věc kterou se musí programátor nadrtit nazpaměť, kdežto v jiných programovacích jazycích to nějak odvodíš a nemusíš si pamatovat celý název funkce do posledního znaku.

[Jendа]

Jde o to, že to rozhraní není matoucí.

Diskuze byla o nepodpoře Unicode v PHP, ne o přehlednosti rozhraní.

[Jendа]

Explicitní kontrola zda je v tomto případě řetězec delší než 1 byte a následné vyvolání warningu je trochu diskutabilní - např. z hlediska výkonu (proč se starat o zbytek když plníte právě jeden bajt).

A taky to pak vede k těm věcem jako v C#, kde nejde double narvat do floatu a musí se to všechno explicitně přetypovávat.

[kralyk z abclinuxu]

Njn, protože strong typing...

[_]

Huráááááá, takže už není zhruba 10x pomalejší než node.js, ale jen 5x. Hurááá ... Přece jenom, po těch desítkách let vývoje, někam se to hýbe ...

[peter]

Mohli ste pouzit aj hhvm. Javascript tu je tiez nejaky ten piatok a rozhybal to az google.

[JoHnY]

To je videt, ze nejsi v obraze. Uz zrychleni mezi PHP 5.3 a 5.6 je nekde mezi 30 a 100% podle aplikace. HHVM je pak na vykonu porovnatelnem s PHP7 minimalne posledni rok.

[Odin1918]

Nekde jsem cetl, ze hhvm v nekterych pripadech silne vede nad php7. Php vsak tak nemiluji, abych si toto tvrzeni overoval. Pokud php udelalo takovyto vykonostni skok, je to jen dobre.

[kozzi]

Ano, a to zejmena diky tomu ze HHVM ma JIT, kdezto PHP 7 ne. Ale pokud se v HHVM vypne JIT, tak je to neuveritelny snek (horsa jak php 5.4) :)

[Max]

Dle dostupných benchů na netu je php7 stále za HHVM. Každopádně většina benchů je o existujících app/cms apod. s legacy kodem.
Je tedy možné, že čistý kód pro php7 bude srovnatelný, nebo rychlejší, ale to jaksi neodpovídá realitě, kdy většinu nezajímá to, co bude za několik let vývoje, ale současný výkon současných cms.
Zdar Max