Ogre's Lab

Преди доста време излезе "протокола" от една сбирка в Париж на PHP разработчиците в който се описва какви са идеите за PHP6 (Minutes PHP Developers Meeting) . Този пост ще коментира някои от точките от гледна точка на разработчик, който пише на PHP.

Вероятно най-добре ще е първо да прочетете документа сочен от горния линк, за да имате представа за какво става въпрос.

1. Unicode

Тук впечатление правят следните неща:

1.5 Filename encoding -- ще има глобален сеттинг "filename_encoding" , който ще определя очаквания от PHP encoding. Предполага се, че това няма да доведе до проблеми, тъй като ще е "прозрачно" за потребителя, а отделно самите инсталационни пакети ще си идва с подходяща стойност по подразбиране.

1.6. Optimizing []

PHP5.x е "известно" със своята бавна работа, сравнено с PHP4.x. Думата "известно" е поставена в кавички, защото досега не съм видял нито едно наистина добро сравнение между двете, което да е адекватно и да отразава използването в "реални" условия. Бенчмаркването на един цикъл, който се превърта 100К пъти не означава нищо -- никой не врърти 100К пъти някакъв цикъл в реални условия, а ако го прави -- то вероятно има някакъв проблем с дизайна на приложението. Както и да е.

Въпросът тук е, че ще оптимизират един от бавните оператори какъвто е []. Това е добра новина, макар че с нищо няма да промени живота на програмистите по отношение на кода.

2. Cleanup of Functionality

Тук нещата стават доста сериозни.

Въпреки че последните години пиша почти изцяло само на PHP, определено смятам, че PHP е един "сладък бъркоч" (sweet mess).

2.1 register_globals

Премахването на register_globals е доста радикално решение, но определено е крайно време гущера да си отреже опашката и да се оттърве от някои недомислици, които само внасят допълнителни източници на грешки.

Накратко казано, премахването на register_globals ще доведе до :

• огромната маса PHP4 приложения няма да могат да бъдат портнати към PHP6, по простата причина , че зависят прекалено силно от register_globals ON.
• на огромна маса от PHP4 програмисти ще им се наложи да научат по трудния начин, защо глобалните променливи и съмнителните автоматики не са добра идея по принцип.

2.2 magic_quotes

Премахването на magic_quotes e добра идея, но доста хора ще останат неприятно изненадани, когато се опитат да си портнат приложенията.

2.3 safe_mode

PHP пичовете са решили да премахнат safe_mode. Това, честно казано, не съм сигурен какъв ефект ще има. На мен лично safe_mode рядко ми е бъркало в здравето, защото в повечето случаи съм работил на dedicated сървъри, където safe mode е било off. В същото време не знам как ще реагират всичките shared хостинг провайдери -- все пак safe_mode им спестяваше известни усилия….

2.10 Dynamic class inheritance

Решено е конструкции от типа:

"if (…) class {…} else class {…}"

да продължат да се ползват.

Според мен това е грешка. При положение, че така или иначе PHP6 няма да поддържа 100%(айде 99%) обратна съвместимост (както php5 с php4) , то определено е безсмислено такива вредни конструкции да остават валидни.

2.12 old type constructors

Стария тип конструктори, които имат същото име, както и класа остават. Както и по-горе, поради липсата на обратна съвместимост, това решение не е най-правилното според мен -- няма да доведе до някакви ползи, а може някоя заблудена душа да се подлъже да ги ползва и чак когато реши да мести един клас в йерархията на наследяването -- тогава да се усети как се е прецакал.

2.13 Case sensitivity of identifiers

Идеята е имената на функциите и класовете да са станат case sensitive, но проблемът е, че отново php пичовете търсят половинчато решение: "We're going to try to find a way to see how we can make this change gradually, but do not "fix" it for PHP 6.". Доводите им са, че много хора били ползвали "грешния" case като например "Header()" или "ImageCreate()".

Честно казано на мен това не ми звучи сериозно. Редовно се налага да променям case-а на модули и приложения, които се опитвам да импортна в моя фреймуорк и с добър инструмент за find & replace (аз ползвам macromedia dreamweaver и ultraedit) това става доста лесно и бързно. Накой веднага може да каже:

"А как ще се replace-нат извиквания от типа:

$а = 'Header';

$a('Location: …');

"?

Ами много просто -- самият engine ще lowercase-ва името на функцията, като среще такова извикване и готово.

4.2 Adding "goto"

:-)

Тук няма да казвам нищо, че ще стане безмислен flame най-вероятно.

4.5 Cleanup for {} vs. []

За моя изненада се оказа, че {} същестувало и работело както []!

Сега щели да махнат {} -- спомевам тази точка, просто ако някой е ползвал тази конструкция да го има на предвид…

4.6 Changes to the shut-up (@) operator that disallow (@ini_set(…))

Проблемът бил, че @ било много бавно и се чудят как да го ускорят.

Аз лично досега почти не съм срещнал случай в който използването на @ да не може се заобиколи, а ако все пак се налага да се използва то това е някъде много надълбоко в low level code и то единствено при инициализацията на приложението -- т.е. бързодействието като цяло няма да се подобри видимо…

5.2 Allow interfaces to specify the __construct() signature

Все още не е решено дали това ще е позволено.

Теоретично, ако ОО модела на PHP беше като хората, такава възможност щеше да е напълно безсмислена, но при липсата на множествено наследяване и при рехавата проверка на типовете и на мен ми се е искало понякога да мога да дефинирам какви параметри може да приема конструктора.

5.6 name spaces

За мен това е най-важното нещо, което ще има (евентуално?) в PHP6. Липсата на namespaces създава страхотни проблеми, когато трябва да се използват 2 или повече големи библиотеки в дадено приложение. В повечето случаи при първия конфликт с име на клас, функция или глобална променлива(!) и цялата идея дава фира. Човек трябва да избира между следните алтернативи:

• да избере коя библиотека да остане и на коя да се намери заместител -- това в повечето случаи не е реална алтернатива. Малко са качествените PHP библиотеки и е трудно да се намери заместител.
• да използва find & replace и да замени всички конфликтни имена с неконфликтни -- това е предпочитаното от мен решение, но за съжаление понякога се оказва временно по простата причина, че човек се заклещва във версията на библиотеката, която е претакал (с часове/дни) с find & replace. Примерно утре излиза нова версия на библиотеката с бъгфиксове и/или някаква нова функционалност и се налага да се минава отново с F & R. Да не говорим, че за вече delivered проекти това даже не е и опция -- просто си седят със старата версия…

Най-лошото в цялата история, че PHP пичовете се оптиват на минат по "тънката лайсна". Поне доколкото прочетоя няколко блога, има вероятност да няма namespaces във PHP6. За мен лично това означава, че въобще няма да си направя труда да премина на PHP6 -- просто няма да има смисъл.

5.7 Using an undefined property in a class with defined properties should throw a warning

В ситуации като:

class foobar {
public $supercalifragilisticexpialidoceous;

function rod() {
$this->supercalifragilistcexpialidoceous = 42;
}
}

$foo = new foobar;
$foo->rod()

се предлага да се генерира Warning. Идеята е за класове, които имат дефинирани член променливи да не може да се сетва чрез __set метода (автоматичния, виж Overloadable Method Calls and Property Accesses), т.е. ако сте си объркали името на член-променливата когато се опитвате да я сетнете -- да се издаде E_WARNING. На мен лично ми звучи адски логично. Дори в PHP5 използвам:public function __set($name, $val) {
throw new TE_No_Such_Property_Exception('Attemp to set not existing object property/no access to property: '.$name.' value:'.$val);
}
Това се намира в най-базовия клас, от който се наследяват всички останали. Ако не си уцелиш името на променливата -- изплющява те изключение.

За огромно съжаление, PHP пичовете не са приели предложението и са оставили един от най-големите извори на бъгове да блика с пълна сила.

Заключение

Всичко написано по-горе изразява мое лично и силно субективно мнение. Честно казано съм разочарован от това накъде отиват нещата с PHP, но може би PHP пичовете имат реални основания да движат нещата в тази посока.

За съжаление PHP явно ще си остане "ламерски" език с добрите и лошите ефекти от това.

This entry was posted by Ognyan Bankov on 2007-04-23 at 05:11:36 and is filed under PHP. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.