PHP6. Вести с фронта.

[WP]

В том и суть что надо убрать обратную совместимость с 4. Тогда все будут вынуждены поставить 5 или 6. А то мракобесие какое-то. Вообще везде к чертям надо 4 стереть и поставить 5

 

[Sad Spirit]

Автор оригинала: tony2001
не слишком репрезентативная аудитория для таких заявлений.
куда там перешли разработчики PEAR - это одно, а все остальные разработчики - это другое.

некая общая статистика есть тут:
http://www.nexen.net/chiffres_cles/phpversion/statistiques_de_deploiement_de_php_en_juillet_2006.php#milieu

Дык, во-первых, мало кто тут читает по-французски, а во-вторых опять статистика по хостерам (насколько я оный французский понимаю).

На самом деле это бесполезная статистика, т.к. интернет вперёд двигают не 90% клиентов хостингов-за-5-баксов. :]

 

[tony2001]

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

>интернет вперёд двигают не 90% клиентов хостингов-за-5-баксов.
смотря что подразумевать под этим.
пока основная масса хостингов на PHP4.3-4.4, обычным среднестатистическим студиям, которых тыщи, достаточно проблематично писать под 5-ку.
и сотни сайтов со своими серверами статистики не делают.

-~{}~ 27.09.06 23:08:

WP
> В том и суть что надо убрать обратную совместимость с 4. Тогда все будут
> вынуждены поставить 5 или 6. А то мракобесие какое-то. Вообще везде к чертям
> надо 4 стереть и поставить 5.

Баян.
"Мы старый мир до основания разрушим, а затем.." (c)

 

[Sad Spirit]

Автор оригинала: tony2001
>интернет вперёд двигают не 90% клиентов хостингов-за-5-баксов.
смотря что подразумевать под этим.
пока основная масса хостингов на PHP4.3-4.4, обычным среднестатистическим студиям, которых тыщи, достаточно проблематично писать под 5-ку.
и сотни сайтов со своими серверами статистики не делают.

Да ну, у меня как-то последнее время не было проблем с распихиванием мелких сайтов под php5+postgresql. А почитаешь местный форум --- я уже с голоду сдохнуть должен. :-D

Серьёзно, я намекаю, что большая часть хостеров предоставит php5, только свистни. А то что свистят мало --- ну так веб-обезьян больше, чем веб-разработчиков. :]

 

[tony2001]

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

 

[camka]

а не планируется внедрение подбного синтаксиса:

function a()
{
    return array(1);
}
echo a()[0];

по аналогии с:

function b()
{
   return new c();
}
echo b()->method();

 

[Rammstein]

Sad Spirit
Я PEAR не использую... опять же хостеры не всегда готовы ставить нужный пакет.

Develar
namespace в TODO имеются, но ещё не реализованы... по крайней мере, на основании этого: http://oss.backendmedia.com/PhP60
Незнаю на сколько это актуально.

-~{}~ 28.09.06 11:46:

camka
Мысль не уловил. Второе работает точно, а первое даже в голову не приходило. Может проще сделать итератор?

 

[Sender]

Rammstein
>Я PEAR не использую... опять же хостеры не всегда готовы ставить нужный пакет.

странно, всегда думал что PEAR это обычные скрипты и не надо хостера мучать из-за них

 

[camka]

Rammstein
Ну порой было б удобной и более лаконичной альтернативой такому, например, синтаксису:

list(,,$type) = getimagesize();

// $type=getimagesize()[2];

Да и, на мой взгляд, достаточно логично - раз можно сразу обращаться к функции, как к объекту, не используя промежуточные переменные, то почему бы не поступать аналогично и с массивами.

 

[tony2001]

а чем отдельная переменная $type удобнее элемента массива $array[0] ?
зачем все эти list(), ()[] ?
или просто так удобнее писать в стиле write-only ?

 

[Alexandre]

В том и суть что надо убрать обратную совместимость с 4. Тогда все будут вынуждены поставить 5 или 6. А то мракобесие какое-то. Вообще везде к чертям надо 4 стереть и поставить 5

в том-то и дело, тогда тормоза перехода еще больше будут.
WP не забывай о коммерческих проектах, которые ни один год уже крутятся на пхп4, и вот хостер установил пхп5 и завалил все проекты... все клиенты свалят от этого хостера.

ситуация 2, есть несколько написанных сайтов еще под пхп3, где register_globals on, переписывать их - нет ни средств компании, ни желания у разработчиков, как я только установлю пхп5, то вся группа этих сайтов - завалится.

 

[camka]

tony2001
Ну если мне нужен только один элемент получаемого из функции массива в последующем коде, и использоваться он будет много раз. Оптимальнее будет обращаться к скалярной переменной, чем к элементу массива по ключу.

Мне кажется, причины, по которым был внедрен синтаксис func()->method() вполне могут быть перенесены и на случай с возвращаемым массивом. Разве нет?

 

[tony2001]

>Оптимальнее будет обращаться к скалярной переменной, чем к элементу массива по ключу.
из чего следует, что все скаляры по определению оптимальнее, чем массивы (а уж про объекты с PPP и говорить нечего), а значит надо ради оптимальности выбросить из кода все массивы и объекты и использовать только строки и числа.
функции желательно тоже не использовать, copy/paste будет оптимальнее.

 

[whirlwind]

А я согласен с camka - так гораздо удобнее и лаконичнее. Только пользы от этого мало. Если бы различались контексты скалярный и списковый, то можно было бы писать контекстозависимые функции. Но это надо было делать в самом начале, а сейчас кому надо переписывать кучу кода. А сами по себе скобки после вызова функции не настолько полезная фича, что бы тратить на нее время.

 

[camka]

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

И каковы же были, в этом случае, причины внедрения подобного синтаксиса для возвращаемых функцией объектов?

 

[Rammstein]

Вроде тайп-хинтинг для return будет....

 

[Wicked]

camka
ты не единственный. Я тоже в свое время этим интересовался. И тоже пришел к вопросу, почему это не сделано, если сделано для объектов.

 

[tony2001]

camka
я не вижу смысла увеличивать лаконичность кода.
наоборот, доп. verbosity ("это массив полученный из ф-ции .., а это элемент массива, полученного из ф-ции ..") добавляет ясности.
посмотрите на перл - вот к чему приводит лаконичность.

 

[whirlwind]

> посмотрите на перл

смотрели, очень понравилось

print scalar(localtime);

($d,$m,$y) = (localtime)[3][4][5];

ЗЫ. только опять же, без контекста такого не получится, а вводить уже поздно

 

[tony2001]

>смотрели, очень понравилось
>print scalar(localtime);
>($d,$m,$y) = (localtime)[3][4][5];

спасибо за чудесную демонстрацию абсолютной нечитабельности таких конструкций.