Bohové jsou šílení
Školení, která pořádám 
Když Rasmus představil svůj plán čistek pro PHP 6, přijal jsem to s povděkem. Problém ale mám s odstraňováním vlastností, které jsou použity ve spoustě skriptů, ale v PHP 6 by už být neměly. Abych to řekl jasně – já je v jazyce nechci, lituji toho, že se tam kdy dostaly, ale když už tam jednou jsou, tak je lepší je tam nechat. Jejich vyjmutí by znamenalo nutnost převádět spoustu skriptů a v nemnoha případech by vedlo k tomu, že by zkrátka nikdy převedeny nebyly a fungovaly by pouze se staršími verzemi. Jsme toho svědky u PHP 5, které už je na světě rok a čtvrt a přesto je nutné pořád vydávat nové verze PHP 4. U PHP 6 by tento jev mohl být ještě horší.
Výrazná změna z nedávné doby je oprava práce s referencemi. I programátoři, kteří se považují za PHP experty se do této pasti chytli. V tomto případě PHP komunita selhala hlavně komunikačně – popis práce s referencemi je v dokumentaci popsán dostatečně dlouho a jejich nesprávné používání mohlo vést k neoprávněným zápisům do paměti – proto byla vytvořena větev PHP 4.4, ale u verze 5 se nepočkalo na PHP 5.1 a změna v setině verze způsobila nefunkčnost spousty skriptů (byť obsahovaly chybu). V informacích k novým verzím tato nekompatibilita nebyla dostatečně zdůrazněná, a i proto vedla v mnoha případech k velkému rozčarování. U PHP 5.1 se tato komunikační chyba snad opakovat nebude.
Při pohledu vpřed nás mohou potkat také zajímavé věci. V PHP dokumentaci je přes čtyři roky uvedeno, že pro přístup k jednotlivým znakům řetězce se používají složené závorky a kvůli zpětné kompatibilitě se dají používat i hranaté, nicméně že tato syntaxe je zastaralá. A ejhle – z PHP 6 má doporučovaný způsob zápisu zmizet a zůstat mají pouze hranaté závorky. Do PHP 5.1 RC 5 (!) kvůli tomu dokonce bylo doplněno varování. Důvod je ten, že [] i {} se při přístupu k prvkům pole i ke znakům řetězce parsují ekvivalentně (přičemž {} pro přístup k prvkům pole je nedokumentovaný), a proto jeden z nich má být odstraněn – [] to být nemůže (protože je zvykem ho používat i v jiných jazycích a používá ho spousta PHP skriptů), takže Černý Petr padl na {}. Uvidíme, zda nářky lidí, kteří se 4 roky snažili psát kód v souladu s dokumentací a vytvořili také nezanedbatelné množství skriptů, budou vyslyšeny.
Další ukázka šílenosti bohů je práce s parametry předávanými interním PHP funkcím. Určitě jste už setkali s hláškou typu Warning: wordwrap() expects parameter 2 to be long, string given. Tuto hlášku produkují funkce, které používají standardní parsování parametrů. Vsadím se, že ušetřila spoustu probdělých nocí jednak programátorům bez pořádného editoru (který jim neříká, v jakém pořadí a jakého typu jsou jednotlivé parametry) a jednak i těm ostatním, kteří nedopatřením předali jako parametr proměnnou nesprávného typu. Jiné funkce (třeba substr) nicméně parametry parsují nestandardně a tuto chybu nevypisují. V PHP 6 má být parsování parametrů sjednoceno (což hodnotím samozřejmě kladně), ale kvůli zpětné kompatibilitě a konzistentnosti má být chybová hláška potlačena. Zpětná kompatibilita v tomto případě znamená, že u starých skriptů, které obsahují chybu, se tuto chybu nedozvím ani v PHP 6, přestože by to bylo možné. A konzistentní má být tento způsob s ručním přetypováním, u kterého ale jasně dávám najevo, že vím, co dělám.
Nechce se mi věřit, že tyto změny navrhuje pořád ten stejný Rasmus Lerdorf, který vytvořil první verze PHP.
Diskuse
Hrubeš:
Pane jo, tak to je hukot. Ale on ten open source musí mít i své nevýhody..mach:
Neřekl bych, že jde o šílenost... Šílenost by bylo něco, co nemá naprosto žádné výhody a tady je jednoznačná výhoda do budoucna.pif:
urcite, vyhoda do budoucna.
Je to ovsem za nejakou cenu. Porad musite resit vecne dilema, zda za sebou tahat berlicky z let minulych, s tim se potyka vubec cely IT svet od procesoru az pres prgm jazyky.
Tezke je najit kompromis, nicmene, jsem pro, aby PHP verze 6 bylo klidne prelomove a kompatibilita nebyla. I za cenu masivniho prepisovani skriptu.
Je to narocna operace, proto by chtelo, aby melo pevne dany rad a uz ted bych mohl psat skripty, ktere budou postupne pripraveny.
Nicmene debilove jsou vsude, takze jsem asi moc velky idealista. Kdyz se koukam na ten zmatek ohledne {} a [], tak se snad uz musim i smat... Osobne mi v tom nic dobreho neprijde, prece kvuli toho, ze se zmeni neco v jadru to neznamena, ze takovy pristup musi byt spatny. Osobne mi to nevyhovuje, mozna i proto, ze jsem takto nauceny - jak sam pises podle manualu, doporuceny postup. Navic takto pak nerozlis pole a retezec. To teda fakt nechapu :)
"If you were new to PHP and you
were going to try to guess how you would get a character offset in a
string, what would your first guess be? Most non-PHP people I have
asked have answered []."
No obavam se, ze novych lidi, kteri prijdou do PHP je tak MOC malo, oproti tem starym, ze todle je fakt trapo argument...
A dalsi skvely argument :)))))))...
"strings where "{$foo{1}}" is much uglier than "{$foo[1]}". "
No asi se necham prekvapit, co nakonec ti bridilove vymysli, hlavne, at v tom neudelaj jeste vetsi bordel...
Jakub Podhorský:
větší bordel už v tom opravdu nejde udělat :)Sachista:
Novych lidi je kazdy rok slusna varka, nebo si snad myslite, ze programatori se uz nerodi?donny:
# Navic takto pak nerozlis pole a retezec.mne prijde takove znaceni ([, ]) logicke, jelikoz retezec je vlastne pole jednotlivych znaku. Jenze PHP k nemu (bohuzel) takhle zjevne nepristupuje, coz je krasne videt pri konverzi se string na array...
klevo:
ja si naopak myslim, ze je to smer spravny.Jakub Podhorský:
no ty věci co tady píšeš jsou skutečně šíleností, ale na druhou stranu prostě se jednou tenhle bordel musí z PHP dostat...teď de o to jenom kdy k tomu dojdeosobně si myslím že je to správnej krok...takhle by se na sebe akorát nesmysli nabalovali a nabalovali až by z toho byl takovej bordel že by se v tom nikdo nevyznal a řešení by byly ještě radikálnější a mnohem těžší
Jakub Vrána 
:
Já jsem byl také zastáncem ostrého řezu, ale po přečtení http://marc.theaimsgroup.com/?l=php-dev&m=112403105002697 jsem svůj názor trochu změnil. Kdybych PHP navrhoval od podlahy, tak bych se na alternativní syntaxe jako endif nebo $a{} VS $a[] vykašlal, ale když už v jazyce jednou jsou, tak jaký je vlastně důvod je odstraňovat? Proti snaze o sterilitu jazyka stojí nutnost předělat spoustu skriptů a tím i podstatně ztížit přechod.
U každé jednotlivé vlastnosti je třeba posoudit, co je lepší. Direktivy register_globals a magic_quotes a konec konců i safe_mode jsou příčinou takového zmatku, že bych je bez váhání odstranil. Ale endif nebo $a{} VS $a[] dohromady ničemu nevadí, navíc u druhého zmíněného se má zanechat způsob, který byl čtyři roky označen jako zastaralý a doporučovaný se má odstranit.
Zrušení varování o špatných typech parametrů je podle mě jasným krokem zpět.
Jakub Vrána : trta:
No, alternativni syntax ridicich struktur (endif atd..) bych zas tak nekritizoval (nerusil), pokud ma programator zavedeny styl, nepouzije to. Na druhou stranu v pripade vkladani php kodu do xhtml stranek (napr. pri tvorbe sablon apod.) je syntaxe if (): endif; mnohem prehlednejsi...Gioel:
Ja by som bol tiez zato ak by bolo PHP 6 kludne prelomove a nebola tam spatna kompatibilita.Ved najdolezitejsie je co bude nie co bolo..
Ak sa nam ma lepsie pracovat s PHP v buducnosti tak sem za...
donny:
jak rika jedno stare a zname prislovi: lepsi zadna kompatibilita nez spatna kompatibilita...endlife:
ad výhoda do budoucna: pokud kvůli problémům s klienty ("náš webhoster přešel na php6, 50 mých projektů nejede, klienti mailují, budu na tom dělat další dva měsíce") bude přechod na php6 příliš náročný, přejde na něj jen minimální množství serverů a php ustrne na pětce (někde čtyřce) - a časem se může stát, že se raděj přejde na jiný jazyk, než zkoušet "to zastaralé php, které v nových verzích není ani pořádně otestované v reálném provozu"..
llook:
Byl bych všema deseti pro přechod na jiný jazyk, ale kdyby se dostatek lidí shodlo na jaký. Já bych byl pro Python, někdo jiný pro Ruby a někdo by chtěl třeba ECMA-262. A nejde jen o jazyk, jde o celou platformu.
PHP má tu výhodu, že se na něm tolik lidí shodne a do jisté míry je všude stejné.
llook: donny:
Ja osobne nevidim zadny vetsi problemy s moznym nastupem "prelomoveho" PHP6. Dokazu si docela dobre predstavit, ze na serveru pobezi dva nebo i tri parsery na php (4,5,6)-neni to technicky nemozne a nejsem si vedom toho,ze by to bylo nejak narocnejsi- a ja proste budu pouzivat treba jenom jeden z nich. Rozliseni verzi podle pripony: .php pro php4, .php5, .php6. Stary skripty budou bezet pres starej parser a ty novy, co budu psat rovnou pro php6, uz muzou pres ten novej. Jedinej rozdil bude v tom, ze novej skript bude mit priponu .php6 - coz podle me nepredstavuje sebemensi problem.god.zilla:
Provozovat na jednom webserveru (mysleno jedna instance Apache) vice php parseru neni jednoduche a urcite ne dostatecne ozkousene :-)Problemy s kompatibilitou jsou uz pri prechodu ze 4 na 5, tolik vyhod nova verze zase neprinasi. Pokud budou vyrazne zmeny v PHP6, kvuli kterym bych musel prepisovat tuny kodu tak se na to vykaslu (a verim ze i dost dalsich lidi).
PHP je hodne pouzivane taky proto, ze je hodne jendoduche & levne nasadit ho na hosting (z pohledu webhostera). Perl/Python/Java/... mi neprijdou jako o nic horsi jazyky, ale sehnat pro ne hostovani da hodne prace tak se pri vyberu vetsinou uplne preskakuji, v .NET zase umi malokdo psat.. uvidime jak to dopadne :-)
Jakub Vrána :
Dvě verze PHP je nejlepší provozovat na dvou instancích Apache (lze zprovoznit např. přes mod_proxy).
V PHP 5 je zásadní novinkou nový objektový model. Kdo ho potřebuje, bez upgradu se neobejde. V PHP 6 bude zásadní novinkou Unicode, s tím to bude stejné.
Jakub Vrána : pif:
presne tak... ve skutecnosti, lidi kteri oceni skutecne poradek a prelomovou verzi jsou tak jedine pokrocili programatori... A reknete mi, kolik jich v dnesnim svete je? To si budeme muset asi zalozit vlastni obcanske sdruzeni a provozovat webhosting :)) (a sakra dobry napad :))))))))
llook:
A kolik jich dělá v PHP?
llook: pif:
taky otazka, ale to bychom asi byli u opusteni php. A to se mi nechce, protoze s dobrym oop je php i tak porad hodne schopne.
Diskuse je zrušena z důvodu spamu.
© 2005-2024 