[Глобально и надёжно][Не наступите] Не знал, не знал :D

Да, забыл ссылку на источник: http://community.livejournal.com/ru_php/1287137.html

действительно, глобально и надежно...

php кардинально повышает КПД руления и педаления.

Глобально&надёжно(tm),да. Кто-то в школе проходил разницу между массивами и хеш-таблицами, а кто-то вроде похапе и Lua решил забить&обобщить. Причём если в Lua >=5.0 специально в виртуальной машине сделали новый тип данных -- массив с целыми индексами и хеш-таблица с любыми, в похапе решили не заморачиваться.

>Кто-то в школе проходил разницу между массивами и хеш-таблицами, а кто-то вроде похапе и Lua решил забить&обобщить.

Ну, в PHP бывает очень удобно. Например, описывать поля в БД так:

$fields = array('id', 'title' => 'name', 'create_time' => 'posted',
'text');

Постоянно такой формат использую :)

А если бы массивы и хэши различались, то облом.

удобно-то удобно, да. А как эта разница в терминах O(n) для времени доступа к элементу {массива,хеша} будет выглядеть?

>А как эта разница в терминах O(n) для времени доступа к элементу {массива,хеша} будет выглядеть?

Любое решение есть некий компромисс между скоростью и удобством. Если нужна _только_ скорость - то смотреть нужно исключительно на машинные коды. Да и то в небольших количествах :D

...

В данном случае производительности хватает для того, чтобы захапать львиную долю массового веба ;)

...

У меня сейчас сервер бОльшую часть времени в idle проводит: http://admin.airbase.ru/munin/airbase/airbase/cpu-day.png

И это не смотря на 1,3 млн. хитов в сутки :) - http://admin.airbase.ru/globalstat/usage_200811.html

Жесть :)

Я вот только никак допереть не могу, почему

Array
(
    [0] => 21
    [1] => 22
    [2] => 22
)

а не

Array
(
    [0] => 21
    [1] => 22
    [2] => 21
)

> Если нужна _только_ скорость - то смотреть нужно исключительно на машинные коды. Да и то в небольших количествах :D

ну почему *исключительно*. Вот, например, есть KLONE для С++, Haxe с ничего_не_поделаешь и чем-то вроде PHP для своей VM.. весьма небольшой trade-off :)

А например вот этот любопытный браузер на форте http://www.forth.org.ru/~profit/ работает быстро, когда не падает. Не потому, что на форте, а из-за концепции "накопителей" (см. дипломную записку). То есть, "HTML парсер" когда строит дерево разбора ничего никуда не копирует, а строки учитывает в виде (длина;указатель_на_начало). В итоге "парсер ХТМЛ на яве" жрёт лишнюю память, а этот -- только маркером указатели расставляет. А саму концепцию "накопителей" можно перенести, и например, на язык D :http://dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/ (см. про array slicing) или С++/RapidXML.

(мда, жалко браузер игрушечный весьма. Вот hv3 с tkhtml -- уже веселее, и там тоже интересная концепция -- генерировать рендерер из описания стандарта CSS, то есть, он всегда должен рисовать корректно по стандарту)

Так что концепции рулят, а дикие хаки вроде предварительной оптимизации и синтаксических удобств -- есть зло :))

> Любое решение есть некий компромисс между скоростью и удобством.

а ещё есть "закон дырявых абстракций"

Ещё лучше хранить строки в виде: (указатель на начало, указатель на элемент после последнего)

$id после первого цикла остаётся ссылкой на $nums[2]

Потом второй цикл:

$id = $nums[0] === $nums[2] = $nums[0] === $nums[2] = 21
$id = $nums[1] === $nums[2] = $nums[1] === $nums[2] = 22
$id = $nums[2] === $nums[2] = $nums[2] === $nums[2] = 22

>Потом второй цикл:

А! Блин! Вот я где протормозил. Я почему-то в голове посчитал, что после первого цикла в $id будет не указатель, а уже значение. Переклинило :)

пых-пых - вообще довольно странный фреймфорк

*ШОК*

ну его нафиг.

Ничё не понял. На похапэ не писал со школы, и слава яйцам.

> Результат ожидаемый

Кстати, почему ожидаемый? В других языках такого просто нет. Область видимости таких переменных типа id сильно ограничена.

>Область видимости таких переменных типа id сильно ограничена.

ога, ничерта непонятно

в смысле "область видимости _должна_ быть сильно ограничена"