Fork PHP
Školení, která pořádám
Jak jsem nedávno poznamenal, tak jsem trochu zneklidněn tím, jak se tříští vývoj MySQL. Na totéž poukazuje i autor článku PHP Hacking, ovšem používá to jako argument pro uvedení vlastní verze PHP.
Této verzi PHP nedávám moc šancí na větší rozšíření ze dvou důvodů:
- Nestojí za ní žádná velká společnost, která by ji masivně používala na svých serverech.
- Změny byly provedeny dost nešťastným způsobem – místo forku a následných commitů s jednotlivými úpravami byl použit snapshot PHP a jeden monstrózní patch se všemi změnami najednou.
Některé změny mi ale i tak přijdou zajímavé:
- Rychlejší strlen a count a jejich úplná eliminace při použití s konstantní hodnotou. Stejný obrat používají i některé optimalizátory a jeho zařazení přímo do PHP by mi vyhovovalo.
<?php
// přehlednější, ale o něco pomalejší
for ($i=0; $i < strlen($s); $i++) {
}
// rychlejší, ale zbytečně komplikované
$strlen = strlen($s);
for ($i=0; $i < $strlen; $i++) {
}
?>
- Dosazení konstant true, false a null už při kompilaci. Řada lidí ani netuší, že to jsou konstanty, ale jakékoliv použití true provádí totéž jako
constant("true")
(kromě zavolání funkce).
- Možnost vypnout $_REQUEST – tuhle proměnnou je stejně lepší nepoužívat.
- Funkce
exists
jako obdoba funkce isset, ale vracející true pro null. Tohle chování mi je bližší a třeba při implementaci metody __isset se k němu často kloním:
<?php
class C {
private $data = array();
function __isset($name) {
// chování podle funkce exists()
return array_key_exists($name, $this->data);
// standardní, ale někdy nešikovné chování
return isset($this->data[$name]);
}
}
?>
- Funkce
str_random
vracející náhodný řetězec dané délky (obdoba Nette\Strings::random
).
- Funkce
sigfig
vracející číslo s platným počtem číslic (ať už před nebo za desetinnou tečkou).
- Funkce
strmap
by se bezvadně hodila pro překlady.
- foreach s řetězci iterovanými po jednotlivých znacích je perfektní nápad, pro praktické použití by to ale muselo fungovat s kódováním UTF-8, což by nebylo konzistentní se zbytkem PHP.
$str[-1]
pro přístup k předposlednímu znaku řetězce je také užitečná zkratka, bez podpory kódování je to ale opět málokdy použitelné.
- Binární čísla zapisovaná jako
0b100
se hodit můžou, zápis vypadá lépe než 1 << 2
používaný při definici konstant.
- Zkrácený zápis polí pomocí
[ 1, 2, 3 ]
místo array(1, 2, 3)
bych uvítal.
- Konfigurační direktiva
ignore_include_warning
pro potlačení chyb při vkládání neexistujících souborů se může hodit při kešování.
- Funkce pro vrácení počtu matchnutých řádků v MySQL (obdoba tipu 558 v mé knize).
- Zrušení zastaralých konfiguračních direktiv mi vyhovuje. Nesouhlasím ale s opětovným snížením
memory_limit
.
- Vypisování false pomocí print_r.
Část nových funkcí by se dala snadno implementovat přímo v PHP, ale mít je k dispozici všude může být užitečné. Některé věci se mi ale zdají zbytečné nebo dokonce škodlivé:
- Optimalizace funkce time – od PHP 5.1 je k dispozici konstanta
$_SERVER["REQUEST_TIME"]
, takže je zbytečné stejné chování přisuzovat i funkci time()
, navíc jen po zapnutí konfigurační direktivy (aktuální čas pak zjistit nejspíš vůbec nejde).
- Funkce
ob_fwrite($fp)
je zdá se jen zkratka za fwrite($fp, ob_get_contents())
.
- Smysl funkce
strcal
jsem nepochopil.
- Změna výchozího parametru funkce microtime – podle mě samoúčelné porušení zpětné kompatibility.
- O změně výchozích parametrů funkce htmlspecialchars se dá říct totéž, já navíc ENT_QUOTES prakticky nepoužívám a změna výchozího kódování ve skutečnosti žádnou změnu nepřináší.
- Příznak funkce json_encode, který způsobí vytvoření výstupu nesplňujícího JSON, je špatný.
- Většina změn v MySQL se mi líbí, ale opět je nevhodná kvůli zpětné kompatibilitě: přetypování výsledků a vracení asociativních polí.
- Funkce
mysqli_return($result)
uvolňující předaný zdroj mi také nepřijde šťastná. Já jsem si pro Adminer napsal funkci, která přijme SQL příkaz, spustí ho a vrátí z něj zadaný sloupec prvního vráceného řádku.
V souvislosti s těmito úpravami stojí za to také prostudovat seznam navrhovaných, přijmutých a odmítnutých změn v oficiálním PHP. Mezi přijatými změnami je např. možnost rovnou pracovat s prvky pole vráceného funkcí: f()[0]
.
Diskuse
marty:
Robert Eisele (autor forku) psal v komentarich, ze mu ani o masivni vyuziti nejde, ale ze jde o proof of concept, ktery mu ma umoznit upozornit na featury, protoze v php bugtrackeru na nej kaslou.
"...I modified PHP as proof of concept in order to get these changes into one of the next releases. That's also why I published it as PHP5.3.6, because it's originated from PHP5.3.6."
Martin Hruška:
Tohle je jen důsledek toho, že PHP není jen jazyk, ale ještě k tomu ohromný balík méně nebo více rozumných funkcí.
Dělá snad někdo fork Javy, Pythonu nebo Ruby, aby mohl mít novou funkci str_random?
Mě to přijde naprosto šílené, ujeté a pokud tohle nedonutí lidi se trošku zamyslet, jestli nedat od PHP ruce pryč, tak už asi nic.
Jakub Vrána :
Žádný zásadní rozdíl nevidím. PHP má celkem malé jádro (které fork upravuje např. kvůli výkonnosti) a knihovnu standardních funkcí (které jsou ale např. na rozdíl od Pythonu napsané v C a ne v „sobě“). Názor na to, co má být v této standardní knihovně a co už ne, se různí.
optik:
A to je právě na prd, kdyby mělo PHP pěknou rychlo VM a základní knihovnu přímo v PHP, rychlost vývoje a hlavně řešení bugů v core PHP bude mnohem větší, takhle je všechno v C hlavně kvůli rychlosti a všechno strašně trvá. Z toho také plyne že PHP je hlavně lepidlo různých C/C++ knihoven, kdežto
Java, Ruby, Python jdou spíše vlastní cestou, což mi přijde lepší. I z toho důvodu je samotné PHP proti nim z mého pohledu mnohem větší moloch.
Je určitě dobře, že do toho někdo pěkně zašťoural, protože to, jak se se vleče vývoj PHP je dost hrůza, třeba se to trochu pohne.
Sidik:
PHP není balík funkcí. Má spoustu rozšíření ale jádro samo o sobě nijak veliké není. Naprostá tragédie je jen syntaxe, hlavně názvy funkcí.
Tady navíc nejde o forkování a vývoj samostatného nového PHP, pouze o ukázku, že navrhované změny opravdu mají smysl a nemělo by se na ně kašlat.
Mezi námi, rychlost aplikací psaných v PHP je i přes ten "ohromný balík méně nebo více rozumných funkcí" pořád mnohem vyšší, než u aplikací psaných v Javě nebo Ruby. Hlavně v případě různých slepenin. A zprovoznit PHP aplikaci je daleko snazší než rozhýbat něco v Javě nebo nedejbože v Ruby. Moc tomu nepomáhá ani téměř nulová podpora jiných jazyků u hosterů (a když už tam něco je, tak to většinou moc používat nejde).
v6ak:
K té rychlosti: mohu se zeptat na zdroj?
Jinak je samozřejmě možné napsat benchmark tak, aby to Java v rychlosti prohrála, myslím, že i vím jak. Ale s vhodným použitím bude rychlejší spíše Java.
Ondřej Mirtes:
Java už z principu musí být rychlejší než PHP (kompilace, statické typování).
v6ak:
Myslím, že důvody jsou poněkud jiné než přidání nějaké funkce. Tu lze, samozřejmě, přidat běžným způsobem, podobně jako v Javě, Pythonu, Ruby etc.
Na druhou stranu, třeba Java má HotSpot (OracleoSun JRE), jeho fork OpenJDK (až na některé outsourcované části shodné s HotSpotem) a jeho fork IcedTea (vyvíjený Red Hatem, odtud se asi přebírají patche zpět do OpenJDK). Pak tu je/byl JRockit (má být AFAIK spojen s OpenJDK a HotSpotem). Čtyři implementace tu budou časem spojeny do jedné. Pak je tu například IBM JDK a nějakou dobu tu bylo GCJ, dnes asi zaříznuté.
A Python? Tam nejsem až tak orientován, ale určitě tu vedle CPythonu je PyPy a Stackless a to ještě nepočítám RPython, Jython a Boo/BooJay, což už jsou možná spíše jiné jazyky.
Nebo Ruby? Vedle Ruby MRI tu je Rubinius a JRuby, mezi Ruby-like jazyky patří třeba Mirah.
V případě Ruby a Pythonu jsem toho napsal poněkud méně než u Javy, ale spíše jde o to, že tam mám větší přehled.
jirik:
ad podpora utf: v gentoo portage se u php predcasem objevily patche, ktere doplnuji nativni podporu pro utf8 do standartnich fci..
Diskuse je zrušena z důvodu spamu.