Что ждать от PHP 6?

Если контора то да конечно, но я надеюсь у меня будет своя контора... хотя всё равно нужно будет работать на дяду какое-то время

>городить там зоопарк

ИМХО это смотря какой сложности заказ. если простенькое то либо свой хостинг либо да не правильно. Если что-то серьёзное, то почему же не стоит? всё равно затраты по разработке-внедрению будут намного выше, чем на установку/настройку/поддержание каких-либо компонентов.

>CMS на ПыхПых будет жрать секунду CPU от 3,4 Зиона, да высеивать пачку

>SQL-запросов (или обращений к отдельным файлам) для _каждого_

>посетителя.

Руцки выпрямляй и на сотню уников в минуту грузиться будет 3% проца максимум.

>$VeryLongVaiableName = $VeryLongVariableName * 3.14159 + 33;

Четайте доки, они рулез...

>В *нормальных* языках, была бы сгенерирована ошибка.

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

>То есть, сначала переменная была массивом, а потом, волшебным образом, стала хэшем. Здорово.

Учи албанский. Массивов как таковых в PHP нет, есть хэши, которые ради специальных случаев (например, попадание в руки долбодятла) мимикрируют под "массив".

>Волшебно. Как ошибку-то в имени переменной найт$VeryLongVaiableNameи?

Опять же, вопрос твоего личного стиля. Заведи обыкновение давать адекватные имена переменным, единообразно юзать кавычки и не пользоваться goto.

>за исключением редких случаев их это не должно волновать.

Волнует и серьезно -- ибо в случае чего им твои, скажем, лисповые извращения потом поддерживать. Не, конечно можно попробовать привязать клиента к себе нестанлартным языком. Но это плохая идея, тебе объяснят...

>юсь всё же не все) не видят ничего плохого в подобных превращениях.

>Слабость php, на мой взгляд, в том, что этот язык позволяет

>программисту вообще ни о чём не задумываться. Ни о проектировании (фирменная

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

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

Тоже верно, "позволяет сделать то, что другим не под силу" :D

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

куда слать резюме?

>> Вот столь ненавидимый PERL, при включенном
>> use strict, просто не запустит такой код. 

>а при выключенном? это, кстати, по-дефолту.

В PERL use strict *можно* включить.
Более того, хороший тон - всегда писать c use strict.
В PHP же такой возможности нет вовсе.

Поэтому код вида 
$VeryLongVarName1 = 10;
{
   // ... ... ...
   $VeryLongVarNamel = $VeryLongVarName1 * 2.728728;
   // ... ... ...
}
при включенной прагме strict отлавливается моментально,
а в PHP - только после разбора всего кода.

Сечешь разницу, Ручечник?

Брехня.

В ПХП, когда ставишь error_reporting в E_ALL, получишь сообщение об uninitialized variable VeryLongVaiableName. "Невозможно, невозможно..." Я, конечно, понимаю -- трындеть не мешки ворочать.

>Учи албанский. Массивов как таковых в PHP нет, есть хэши,
>которые ради специальных случаев (например, попадание в руки долбодятла) мимикрируют под "массив". 

Если у Вас хватит квалификации, загляните в Zend C-API.
Внутреннее представление хэшей и массивов в PHP *разное*.
Это только для PHP-кодеров хэши и массивы *снаружи* выглядят одинаково,
а *внутри* все не так.

>>Волшебно. Как ошибку-то в имени переменной найт$VeryLongVaiableNameи? 

>Опять же, вопрос твоего личного стиля. Заведи обыкновение давать адекватные имена переменным,
>единообразно юзать кавычки и не пользоваться goto.

Понятно. Другими словами: ошибку средствами PHP не найти никак. Спасибо за ответ.


Забавляют меня PHPшники. Когда был register_globals они писались от радости, как это круто --
все данные из запроса уже есть в виде переменных. Когда же им намекали, что это, мягко говоря,
неправильно -- авторегистрировать переменные, была буря криков, что все такие тупые и не секут
модных фишек. Как только официальная политика сменилась и register_globals сочли полным аЦтоем,
все тут же начали вопить, как это хорошо, когда есть суперглобальные массивы.

Уверен, когда-нибудь в PHP появится необходимость декларировать переменные. И ВОТ УЖ ТОГДА
будет ну такое вселенское ликование, что небеса упадут на землю.


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

Юноша, задачи компьютерной лингвистики не решаются на PHP. PHP - веб-ориентированный язык.
Если Вы используете его для задач компьютерной лингвистики, значит, Вы ошиблись не только в 
выборе инструмента, а еще и в выборе своей профессии.
Кстати, не затруднит ли Вас привести ссылки на свои работы по компьютерной лингвистике?

>Брехня. 
>В ПХП, когда ставишь error_reporting в E_ALL, получишь сообщение об
>uninitialized variable VeryLongVaiableName. "Невозможно, 
>невозможно..." Я, конечно, понимаю -- трындеть не мешки ворочать.

Возмутительно лживое заявление.
Проверьте вот этот код:

test.php
<?
   error_reporting(E_ALL);

   $CoolVariableName = 10;

   {
      $CoolVariab1eName = $CoolVariableName * 2.728 + 10;
   }
   echo $CoolVariableName;
?>

php -v
PHP 4.3.10 (cli) (built: Jan 19 2005 19:32:58)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

php test.php
10

>Уверен, когда-нибудь в PHP появится необходимость декларировать переменные. И ВОТ УЖ ТОГДА будет ну такое вселенское ликование, что небеса упадут на землю.

Не. Когда-нибудь php сольётся с perl (то есть всё позитивное, что есть в php, если есть, уйдёт в perl) и вот тогда пыхпыховцы будут глотки драть о том, что это и была big idea, и что perl до слияния был полным ацтоем.

>Брехня. >В ПХП, когда ставишь error_reporting в E_ALL, получишь сообщение >об uninitialized variable VeryLongVaiableName. "Невозможно, >невозможно..." Я, конечно, понимаю -- трындеть не мешки ворочать.

Хорошо, усложняем задачу: test.php <? error_reporting(E_ALL | E_STRICT);

$CoolVariableName = 10;

{ $CoolVariab1eName = $CoolVariableName * 2.728 + 10; } echo $CoolVariableName; ?>

php -v PHP 5.0.5 (cli) (built: Nov 29 2005 10:47:55) Copyright (c) 1997-2004 The PHP Group Zend Engine v2.0.5, Copyright (c) 1998-2004 Zend Technologies

php test.php 10

Проще говоря: Вы, гражданин shimon, мало того, что пустозвон, Вы еще и язык толком не знаете.

>Брехня. 
>В ПХП, когда ставишь error_reporting в E_ALL, получишь сообщение об 
>uninitialized variable VeryLongVaiableName. "Невозможно, 
>невозможно..." Я, конечно, понимаю -- трындеть не мешки ворочать.


Хорошо, усложняем задачу:
test.php
<?
   error_reporting(E_ALL | E_STRICT);

   $CoolVariableName = 10;

   {
      $CoolVariab1eName = $CoolVariableName * 2.728 + 10;
   }
   echo $CoolVariableName;
?>

php -v
PHP 5.0.5 (cli) (built: Nov 29 2005 10:47:55)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.5, Copyright (c) 1998-2004 Zend Technologies

php test.php
10

Проще говоря: Вы, гражданин shimon, мало того, что пустозвон,
Вы еще и язык толком не знаете. 

>Повторяю: Вечер волшебных превращений.

>Проблема даже не в том, чем была и чем стала переменная. И что скорость адресации упала на порядки.

>Проблема в том, что свойства переменной $A зависят от свойств переменной $B. Хотя переменные $A и $B не связаны так называемыми отношениями родства и в общем случае не должны никак влиять друг на друга.

Ты некорректно ставишь задачу (иначе и быть не может, ведь ты онанимус)

Я писал в условиях, что эти куски кода выполняются независимо друг от друга

> Проще говоря: Вы, гражданин shimon, мало того, что пустозвон, Вы еще и язык толком не знаете.

Я толком знаю, чем язык отличается от среды выполнения, в отличие от.

>Ты некорректно ставишь задачу (иначе и быть не может, ведь ты онанимус)

Кончились аргументы?

>Я писал в условиях, что эти куски кода выполняются независимо друг >от друга.

Еще раз и медленно: Поведение $A не должно зависеть от того, как к ней обращаются. $A[$B] должно быть *либо* массивом, *либо* хэшем. А не превращаться волшебным образом из одного в другое.

Попытайтесь понять, что доступ к элементу по индексу массива и доступ по индексу хэша - принципиально разные по скорости и трудоемкости осуществления вещи.

И если среда выполнения языка позволяет незаметно для программиста уменьшить скорость с одной операции до O(log_2(N)), значит, среда исполнения никуда не годится.

>> Проще говоря: Вы, гражданин shimon, мало того, что пустозвон, >> Вы еще и язык толком не знаете.

>Я толком знаю, чем язык отличается от среды выполнения, в отличие от.

Судя по Вашим ответам, нет.

даааа, использовать две разные переменные CoolVariableName и CoolVariab1eName может тока басист со стажем :-)

>даааа, использовать две разные переменные CoolVariableName и 
>CoolVariab1eName может тока басист со стажем :-)


Еще раз и для тупых:
Я привел пример ОШИБКИ в коде. И спросил, как
эту ошибку обнаружить *средствами языка*.
Выяснилось, что никак.

Был дан совет использовать более другие имена переменных.
Разумеется, это совсем-свосем не костыльный подход :) :)

А дебаты продолжаются, ужоб успокоились...

> Хорошо, усложняем задачу:
> test.php

Конечно же 10
C:\PHP>php-cgi.exe -v
PHP 5.0.3 (cgi-fcgi) (built: Dec 15 2004 08:07:52)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.3, Copyright (c) 1998-2004 Zend Technologies

Конечно 10. Было бы странно, если не так.

Но разговор о том, как *найти* ошибки такого типа. И способов нахождения *таких* ошибок методами PHP *нет*.

Головой работайте, молодой человек, раз разработчики ПХП не удосужились.

Кровные 500 баксиков никак _отрабатывать_ надо :)

> разговор о том, как *найти* ошибки такого типа.

Как?
Очень просто. Не выбирать инструмент ради "быстрого старта", а планировать заранее.
Тут кто-то советовал "руки выпрямлять", но как ни выпрямляй, а один и тот же алгоритм ПыхПых прогоняет с затратами в 100-200 раз бОльшими, нежели нормальные инструменты (при этом нормальные инструменты не отъедают в 100 раз больше памяти).
К тому же средств обеспечения "прямизны" в нём нет.

В общем, ПХП в шкапчик, как исторический курьёз до тех пор, пока не сделают:
1. Just-in-time/Ahead-of-time компиляции
2. Нормальной типизации
3. Указания источника данных и времени жизни до обновления объектов. Нормального, без костылей.
Но этого не будет, т.к. Зенду нужно продавать "оптимайзеры".
Так же как не будут никогда хорошими продукты, поставщики которых основной доход получают от поддержки.

>Так же как не будут никогда хорошими продукты, поставщики которых основной доход получают от поддержки.

Намекаешь на линукс? :))))))))))))

>Еще раз и медленно: Поведение $A не должно зависеть от того,
>как к ней обращаются. $A[$B] должно быть *либо* массивом, *либо*
>хэшем. А не превращаться волшебным образом из одного в другое.

ничего никуда не превращается, смотри:

<?
$A[0] = "a";
$A["a"] = "b";
$A[1] = "c";
var_dump ($A);
?>

выводит:

array(3) {
  [0]=>
  string(1) "a"
  ["a"]=>
  string(1) "b"
  [1]=>
  string(1) "c"
}

т.е. одна и та же переменная является и массивом, и хэшем, понял?

да, перл конкретно так не умеет, у него @A и %A, но короче ты от этого умнее не кажешься. И хватит уже брызгать слюною, >>>RTFM<<<!!!

Юноша, поймите. Адресация в массиве - это всего лишь вычисление смещения от адреса начала массива.

Адресация в хэше - это ВСЕГДА поиск со скоростью O(log_x(N)). Где x (основание логарифма) - это количество ветвей в дереве, обычно - 2.

Попытайтесь понять, что, да, СНАРУЖИ оно выглядит ОДИНАКОВО, но с точки зрения Zend C-API хэш и массив - СОВЕРШЕННО РАЗНЫЕ ВЕЩИ.

Не верите -- загляните в описание Zend C-API. Все, подчеркиваю *ВСЕ* экстеншены PHP пишутся именно на Zend C-API. Так вот, доступ к элементу *хэша* и *массива* РАЗНЫЙ.

> Адресация в хэше - это ВСЕГДА поиск со скоростью O(log_x(N)). Где x
> (основание логарифма) - это количество ветвей в дереве, обычно - 2.
>
> Попытайтесь понять, что, да, СНАРУЖИ оно выглядит ОДИНАКОВО, но с
> точки зрения Zend C-API хэш и массив - СОВЕРШЕННО РАЗНЫЕ ВЕЩИ.

А при чем здесь API? Мы же о языке говорим, не правда ли? Так вот,
семантика PHP в данном случае - любой массив является ассоциативным. Не
могу сказать, что мне это сильно нравится, но в принципе подход имеет
право на существование. В Lua, например, так же. Как это реализовано под
капотом - другой вопрос...

>А при чем здесь API? Мы же о языке говорим, не правда ли?
>Так вот, семантика PHP в данном случае - любой массив является 
>ассоциативным. 


Да притом, что, повторяю:
Адресация в хэше - это ВСЕГДА поиск со скоростью O(log_x(N)).
Где x (основание логарифма) - это количество ветвей в дереве,
обычно - 2.

А это значит катастрофическое падение производительности
при работе с массивами.
Я понимаю, надо же продавать за деньги свой Zend-акселератор,
но нельзя же так откровеннно гнать лажу.

>Как это реализовано под капотом - другой вопрос...

Нет, это как раз первейший вопрос. Вот если бы дела обстояли
также, как с языком C, для которого есть куча компиляторов,
и есть из чего выбирать, тогда да, можно было сказать о кривизне
*конкретной* среды выполнения, написанной в Zend.

А поскольку *среда выполнения* для PHP одна -- первая, она же и
последняя, то увы и ах, виноват весь язык, допускающий кривые 
конструкции.

P.S. Подход "не нравится - напиши сам", увы, к PHP неприменим.
В этом языке нет ничего такого, что может потребовать необходимости
пользования им и только им.

2Nuke - poshel na xuy estet. Ili dokagi chto ti ne mraz` - narisuy na Lispe mne kod, kotoriy bil poluchal maticu wtorix proizwodnix (hessian) i gradient na wxode, a widawal na wixode shag (zadacha mnogomernoy optimizacii). Wnutri twoey lispowoy podelki chtobi ispol`zowalas` Pade[2/2] k LQA. Nu che ?

> Да притом, что, повторяю:
> Адресация в хэше - это ВСЕГДА поиск со скоростью O(log_x(N)).
> Где x (основание логарифма) - это количество ветвей в дереве,
> обычно - 2.

O(log n) - это красно-черные деревья, которые к хэшам никакого
отношения не имеют. О скорости хэш-таблицах имеет смысл говорить только
статистически, т.к. там O(1) в лучшем случае и O(n) в худшем, и в
среднем сильно зависит от прочих параметров (размер таблицы etc). Я не
знаю, как ассоциативные массивы сделаны в PHP, возможно, и
RB-деревьями. Но будьте добры не путать термины.

> А это значит катастрофическое падение производительности
> при работе с массивами.

А что, с этим кто-то спорит? Просто предполагается, что массивы не есть
основная структура данных в PHP, соответственно, их "соптимизировали"
под простоту использования, введя один универсальный тип вместо трех
(по-хорошему нужно как минимум векторы, связанные списки, и
ассоциативные массивы). Точно так же, как в JavaScript и Lua. Это
было вполне вменяемое design decision - другой вопрос, что то, как
позиционируется PHP5+ сейчас, вряд ли ему соответствует.