Собираем вопросы авторам PHP - они ответят на PHPConf 2008

[confguru]

Собираем вопросы авторам PHP - они ответят на PHPConf 2008

Появилась идея собрать самые лучшие вопросы авторам PHP,
которые приедут пообщаться на PHPConf 2008.

Предлагаю собирать их в этом топике до 15 мая.

P.S. Чур вопрос когда будет goto в PHP не предлагать..
P.S.S. Часть вопросов уже задана на http://habrahabr.ru/blog/php/40663.html

 

[WP]

Когда будет нормальный сборщик мусора? Который удаляет из памяти объекты? Предлагаю ввести функцию destroy_val которая будет уничтожать значение по ссылке, независимо от того сколько существует других ссылок (в отличие от unset).

 

[domino]

как на счёт типа enum ?

 

[diamond_krnl]

планируются ли нормальные(не eval и create_function) лямбда-функции (официальная поддержка)?

 

[tony2001]

>P.S. Чур вопрос когда будет goto в PHP не предлагать..
Уже есть в PHP 5.3.

>Когда будет нормальный сборщик мусора? Который удаляет из памяти объекты?
Уже есть в PHP 5.3.

>Предлагаю ввести функцию destroy_val которая будет уничтожать значение по
>ссылке, независимо от того сколько существует других ссылок (в отличие от unset).

Так нельзя делать - все остальные ссылки будут указывать в никуда.

 

[himic]

Можете расказать о развитии связки PHP + Oracle, очень уж проблематично связать эти вещи. Предлагаю пойти по пути MySQL.

 

[tony2001]

>Можете расказать о развитии связки PHP + Oracle
Связка PHP + Oracle отлично работает.
Если вас интересует что-то конкретное - уточните.

>очень уж проблематично связать эти вещи.
Связывание этих двух вещей заключается в паре команд:
1) установка instant client;
2) установка oci8.
Всё очень просто.

Если что-то надо добавить в мануал - дайте мне знать.

>Предлагаю пойти по пути MySQL.
Я очень сомневаюсь, что путь MySQL вообще кто-то сможет повторить.

Во-первых, Oracle, в отличие от MySQL, это плохо документированное медленно работающее закрыто-секретное написанное в 80-х годах чудовище, к которому на кривой козе не подъедешь.
Во-вторых, MySQL сам занимался развитием связки PHP+MySQL - все экстеншены для работы с ним были написаны людьми из MySQL или, как минимум, при их тесном сотрудничестве.
В принципе, Oracle тоже в последнее время проявляет активность в этом направлении, но это скорее инициатива конкретного человека (Chris Jones), чем проявление заинтересованности компании.

 

[diamond_krnl]

tony2001 меня не услышал

 

[iamFake]

заменит ли php-fpm(anight) стандартный fpm по дефольту?

ну и вопросец который всегда интересовал =)

компиляция скриптов в бинарный код это - фантазия, сложно-реализуемо или не подходящая возможность для пхп (т.к. теряется кросплатформенность присущая байт-коду) ?

 

[tony2001]

diamond_krnl
http://wiki.php.net/todo/php60 - TODO для 6.0
http://wiki.php.net/todo/php53 - TODO для 5.3

было несколько предложений, все они не были приняты.
я лично пока не вижу вообще смысла в таком функционале, хотя если будет хороший патч, то почему бы и нет.

-~{}~ 07.05.08 12:48:

>заменит ли php-fpm(anight) стандартный fpm по дефольту?
До тех пор, пока патч Найта под GPL, об этом говорить особо смысла нет.
Это не чья-то прихоть, проблема в требованиях GPL, которых не содержит лицензия PHP, из-за чего GPL-ный код не может быть частью PHP.
Когда сменит лицензию, тогда и посмотрим.

>компиляция скриптов в бинарный код это - фантазия, сложно-реализуемо или не
>подходящая возможность для пхп (т.к. теряется кросплатформенность присущая
>байт-коду) ?

ИМО фантазия.
При этом теряется смысл PHP и масса его функционала.
Нужен бинарный код и максимальная скорость - пишите на C.

 

[Alexandre]

До тех пор, пока патч Найта под GPL, об этом говорить особо смысла нет.

а какой смысл тогда его распространять под GPL, если можно сменить лицензию на PHP и включить патч в дистрибутив.

 

[diamond_krnl]

ясно, спасибо, следовательно и о mixing даже мечтать не будем:

public function ClassName::methodName($args)
{

}
/* или  как вариант */
ClassName::methodName = public function($args)
{

}

я просто пытаюсь понять путь развития php, в какаю сторону больше: императивность или функциональность.

 

[idler]

optional typehinted parameters DONE (derick) - это из todo для 5.3 - что это такое?

Обсуждения в internals по поводу Traits так просто затухли на обсуждении синтаксиса... Будет ли добавлен этот патч, если да - то в какую версию?

Стоит ли ожидать в ближайшее время документацию по SPL ? ( я даже готов заняться переводом )

 

[tony2001]

Alexandre
>а какой смысл тогда его распространять под GPL, если можно сменить лицензию
>на PHP и включить патч в дистрибутив.

а какой смысл задавать этот вопрос мне?
я на него по определению не могу ответить - я же не Найт.

-~{}~ 07.05.08 13:21:

diamond_krnl
ой, нет, ой не надо такого.
еще больше syntax sugar для удовлетворения нужд 10-ти человек.
нет-нет, я точно против такого.

-~{}~ 07.05.08 13:26:

idler

>optional typehinted parameters DONE (derick) - это из todo для 5.3 - что это такое?

судя по описанию - тайп-хинты для необязательных параметров.
честно говоря, первый раз слышу.

>Обсуждения в internals по поводу Traits так просто затухли на обсуждении синтаксиса...
Что в очередной раз подтверждает тезис "если чего-то нет, то оно не особо и нужно".
Если бы была реальная польза и необходимость - были бы и добровольцы.
А раз желающих тратить время нет, то логично предположить, что не сильно и хотелось.

>Будет ли добавлен этот патч, если да - то в какую версию?

Сам же сказал, что обсуждение затухло.
Никаких секретных планов нет, все дискуссии - на виду.

>Стоит ли ожидать в ближайшее время документацию по SPL? ( я даже готов заняться переводом )

А что, её нет? =)

 

[MVH]

В PHP для именования функций, переменных, констант и т.п. изначально использовалась нотация Lower Case.
Однако в классах Exception и т.п. используется Венгерская нотация.

Вопрос:
Зачем они сделали такую кашу? И собираются ли они приходить в итоге к единому стандарту в именовании?

Лично мне для именования ф-й и т.п. больше нравиться нотация Lower Case и стиль именования Венгерской нотации мне кажется нелогичным, т.к. возникает неоднозначность при написании сокращений (например, getByID или getById), каша при написании аббревиатур (getURLById, getHTMLLinks и т.п.) и прочая путаница, связанная с перемешиванием букв различного регистра.

Нотация Lower Case, ИМХО, проигрывает Венгерской нотации только тем, что занимает больше знакомест, т.к. слова в ней разделяются символом подчёркивания (правда, не думаю, что это хоть сколько-нибудь важно для PHP в наше время), и, возможно, тем что shift зажать быстрее получается, чем написать символ подчёркивания.

P.S: говоря о Венгерской и Lower Case нотациях я имел ввиду только стиль разделения слов, а не связь между типами данных и названием.

 

[himic]

Автор оригинала: tony2001
>Можете расказать о развитии связки PHP + Oracle
Связка PHP + Oracle отлично работает.
Если вас интересует что-то конкретное - уточните.

>очень уж проблематично связать эти вещи.
Связывание этих двух вещей заключается в паре команд:
1) установка instant client;
2) установка oci8.
Всё очень просто.

ДА, это сейчас мне и вам просто связать PHP + оракл клиент.
Но я прошёл долгий путь пока добился этого. Особенно под Linux.
Хотелось бы, для работаты с OCI8,использовать одну библиотеку, как это обстоит с MySQL.
Надо поддержка, скачал подключил и всё.

 

[tony2001]

>ДА, это сейчас мне и вам просто связать PHP + оракл клиент.
>Но я прошёл долгий путь пока добился этого. Особенно под Linux.

Под Linux это особенно просто сделать: `rpm -i oracleinstantclient*.rpm && pecl install oci8`.
В чем проблема-то?

>Хотелось бы, для работаты с OCI8,использовать одну библиотеку, как это обстоит с MySQL.

Именно так оно и обстоит. Скачал 1 (один) Instant Client и собрал экстеншен.

>Надо поддержка, скачал подключил и всё.

Это вы как раз про Windows и PHP4 говорите.
Клиентская .dll от MySQL уже много лет распространяется отдельным файлом, а под *NIX уже точно никто статически собранное не распространяет, т.к. это только добавляет проблем с обновлением.

По поводу проблем с установкой Instant Client - это к Oracle.

-~{}~ 07.05.08 13:59:

MVH
>В PHP для именования функций, переменных, констант и т.п. изначально >использовалась нотация Lower Case.

Насчет переменных - это каждый сам себе решает.
Атрибуты, функции и константы - в стиле C (lower case через подчеркивания).
Классы и методы - в стиле C++/Java (camel case).
Всё это описано тут: http://cvs.php.net/viewvc.cgi/php-src/CODING_STANDARDS?revision=1.39&view=markup

Я вижу чёткую логику, о какой каше идёт речь?

>И собираются ли они приходить в итоге к единому стандарту в именовании?

Как вы себе это представляете?
"С 1-го июня мы переименовываем все функции и классы, всем пользователям немедленно переписать весь код"?
Да и в чем смысл таких изменений? Потакание эстетическим вкусам?

>Лично мне для именования ф-й и т.п. больше нравиться нотация Lower Case и
>стиль именования Венгерской нотации мне кажется нелогичным, т.к. возникает

У каждого свой вкус, всем сразу угодить нельзя.

>неоднозначность при написании сокращений (например, getByID или getById)

getByID и getById - это одно и то же, имена функций/классов/методов не чувствительны к регистру.

 

[MVH]

tony2001
>Я вижу чёткую логику, о какой каше идёт речь?

Мне кажется нелогичным то, что "Атрибуты, функции и константы - в стиле C (lower case через подчеркивания)", а "Классы и методы - в стиле C++/Java (camel case)". Чем плохи классы в Lower Case?

-~{}~ 07.05.08 14:19:

tony2001
>имена функций/классов/методов не чувствительны к регистру.
А свойств - очень даже чувствительны.

-~{}~ 07.05.08 14:21:

tony2001
>У каждого свой вкус, всем сразу угодить нельзя.
Так и я про то же! Продолжали бы традиции Lower Case и в классах...

 

[tony2001]

>Чем плохи классы в Lower Case?
Не совпадают с моими личными представлениями о красоте кода.

>А свойств - очень даже чувствительны.
А свойства, как раз, рекомендуется называть так же, как и переменные.

>Так и я про то же!
Нет, ты говоришь о том, что надо _поменять_ уже установленные правила, потому что тебе лично так больше нравится.

>Продолжали бы традиции Lower Case и в классах...

mysql_error, pg_ping, mysql_query, mail, imap_header, sqrt, imagechar - это название функций или классов?

При существующем порядке наименования мне достаточно одного взгляда, чтобы понять, что речь идёт о функциях.
А при всеобщей каше в lower case мне бы пришлось идти в мануал и смотреть - класс это или функция.

 

[MVH]

tony2001
>Не совпадают с моими личными представлениями о красоте кода.
Думаю красота в коде должна стоять далеко позади понятности (или как это правильно называется).
Вы же его в галереи, рядом с картинами, не повесите?
Стиль именования должен быть прежде всего направлен на снижение кол-ва ошибок и на простоту его восприятия и запоминания, что и обеспечивает lower case и НЕ обеспечивает венгерская и верблюжья нотации (на мой взгляд).

>А свойства, как раз, рекомендуется называть так же, как и переменные.
А зачем это всё держать в голове (как именовать переменные, методы, функции, классы и т.п.), а не применять везде единые правила именования?

>Нет, ты говоришь о том, что надо _поменять_ уже установленные правила, потому что тебе лично так больше нравится.

Честно говоря, я не поменять предлагаю, а хочу разобраться и определить для себя правила именования. Вот и думаю, зачем надо было следовать стилю Java (где, насколько я знаю, в встроенных классах/методах и т.п. lower case вообще не применяется), а не продолжать lower case? На мой взгляд, это слепое следование моде.

>mysql_error, pg_ping, mysql_query, mail, imap_header, sqrt, imagechar - это название функций или классов?

Это всё функции. Методы вызываются как class::method() или $obj->method(). Каким образом их можно перепутать??? Да и к тому же, многие ф-и и методы состоят из одного слова и соответственно одинаково пишутся в обеих нотациях. Тот же sqrt - каким образом Вы определите метод это или ф-я, используя данные правила именования?

>При существующем порядке наименования мне достаточно одного взгляда

Взгляда куда? Где можно увидеть название и не понять что это — ф-я или метод класса? В коде? В мануале? На заборе?