Коллекции объектов в PHP

Очередная попытка из букв P, H и P собрать слово Java?

В этот раз хотя бы грамотная, поэтому +.

Реквестирую в тред jpg-нацистов!

В java или C#, коллекции были заложены в язык изначально, и основной профит от их использования это то, что некоторые коллекции дают упорядоченность при помещении в них элементов, какие-то оптимальны для случайного доступа, какие-то для последовательного…

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

А чем ваша реализация отличается от SplObjectStorage?

Было бы удобнее работать с коллекциями нативным способом. Т.е. заменить

$list->each(function(){...});

на

foreach ($list as $k=>$v) {...}

Иначе не понятно, как в итерабельную функцию передать внешнюю переменную? Неужели через $GLOBALS?

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

странное желание. Мне всегда казалось что у массива/«хеш массива» должна быть одна функция: быстрое извлечение данных по ключу.
Всякие накрутки типа: ключами могут быть объекты — это удар ниже живота по производительности.

Если есть такое, ну очень большое желание, то за 5 мин можно написать простую обертку, которая сериализует объект(часть объекта) и использует результат в качестве ключа.

Зачем так

use \UnexpectedValueException as UnexpectedValueException;

если можно просто так

use UnexpectedValueException;

Самостоятельный контроль типов объектов в массиве.

а не лучше ли использовать для этой цели собственный враппер, тоже пишется за 5 мин :).
Мне, например, часто требуется использовать массив, как универсальный стораж, в котором могут буть разные типы. Не забываем, что РНР идеалогически разрабатывался как язык с НЕ СТРОГОЙ типизацией!
Да, в этом есть плюсы и минусы. Не нравится не срогая типизация — перелезайте на рельсы!

Самостоятельный контроль последовательности индексов в списке.

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

Возможно разработчикам РНР и нужно было сделать две отдельных сущности: массивы и хештайблы? Но, разработчики пошли по пути универсализации. Все довольны, все в шоколаде!

в целом проект грамотный и интересный

Дал плюс за креативность и грамотную реализацию, но тем не менее пользу вижу только в возможности работы по объекту как по ключу. Однако учитывая реализацию строго на PHP, эта польза нивелируется — можно было ограничиться реализацией лишь пары вспомогательных функций к стандартному массиву.
Итого(уж извините за критику, но взгляд со стороны часто находит простое в сложном): вы сделали, как справедливо заметил выше hom, бесполезное усложнение архитектуры.
Обычно, если нужно работать с объектами столь гибко, делается так: пишется класс обвязки к стандартному массиву, оперирующий самогенерирующимися ключами, строковыми или числовыми, и внутренним объектом, который является обычным массивом.
То есть когда вы потом напишете например $col->remove($obj), у вас $obj будет(и должен быть) не самим объектом, а его ключем в коллекции $col. Фактически это разновидность псевдопоинтера.
Соответственно работать с такими объектами вы будете не как $obj->method(), а как $col->get($obj)->method() или подобным образом. Компилятор сам вам подскажет, если вы забудетесь и попытаетесь вызвать $obj->method().
Контролировать типы объектов можно либо самому, либо включая в каждый объект метод либо свойство, отвечающее за тип. Таким образом при желании вообще можно в коллекцию помещать как ООП-объекты, так и обычные структуры, и работать с ними, не путая типы. Кстати работать можно будет как полностью с процедурным подходом, так и с объектным.

Плюс такого подхода в том, что аналоги перлового хеша в стандартный PHP-массив уже встроены — это ассоциативный массив. А следовательно, поиск значений по простому ключу будет гораздо быстрее любой другой реализации, написанной на самом PHP, иными словами: быстрее любого нативного перебора. То есть суть класса обвязки сводится лишь к группировке функций обслуживания такой «коллекции»(большинство из которых в языке уже есть нативно, а соответственно, работают быстрее) и скрытие внутри вспомогательных массивов-хешей.

>>Исторически сложившиеся имена функций и отсутствие ОО интерфейса
Это бесит только первые пять лет :)

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

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

Use SplObjectStorage, Luke.

и еще капля дегтя…
Очереди и списки интересны, если они производительны. Может я однобоко гляжу в сторону разработки, просто я последние пять лет сильно упираюсь в производительность.
При необходимости использования этих структур, я бы реализовал их в в виде РНР-расширения. Кажется я даже встречал такую реализацию. Можно покапаться в просторах инета…
У меня самого пару лет назад была такая идея, но не нашлось проекта для применения. И я бы туда еще добавил деревья. Как смотришь на это?

Только вот не вижу практической реализации. Как правило, если мы создаем эти структуры, то поиск/извлечение информации должны быть персистентные, а не временные (на одну итерацию выполнения скрипта). Таким образом это все имеет смысл, если все это хозяйство держать в разделяемой памяти или в в виде отдельного демона.
Но, реализация в в виде отдельного демона уже есть: это редис или тарантуул. Так что, я даже и не знаю на какой ноте завершить свой комментарий.

Ваши коллекции — вещи сами по себе. Создать, заполнить последовательно по одному ключику, вынуть по ключику. И всё.

Как предлагается обрабатывать коллекции как единое целое: сортировать, преобразовывать, конвертировать, фильтровать? Стандартные функции массивов принимать ваши коллкции не будут. Конвертировать туда-сюда? Не выйдет из-за объектов-ключей, да и окончательно убьёт производительность. Или предлагаете ради каждой новой функции лезть в сорцы коллекции и реализовывать всё вручную? Так теряется весь профит от использования «библиотеки»: сам дописывай, сам тестируй, сам исправляй баги.

По вашим коллекциям даже нельзя пройтись с помощью foreach — нужно использовать изобретённые вами же методы. Отдать в какой-то код «снаружи» коллекции нельзя, они из станданртных интерфейсов только Countable поддерживают (коллекция, у которой можно вычислить размер, но нельзя получить элементы — лолшто?).

Похапэ и так производительностью не отличается, так вы ещё реализуете немало методов с помощью полного прохода, весь код array_search утыкан.

После просмотра функции getHash сразу возникают вопросы.

    public function getHash($value)
    {
        if (is_object($value)) {
            return spl_object_hash($value);
        }

        if (is_string($value)) {
            return md5($value);
        }

        if (is_array($value)) {
            $value = serialize($value);
        }

        return md5($value);
    }

Почему для объектов всегда используется spl_object_hash? А если у меня два объекта считаются равными, если их id совпадает?

Зачем для строк вычислять md5? Похапэшные массивы — и так хэштаблицы, не нужно вычислять хэши на двух уровнях. Только память и вычислительные ресурсы впустую расходуются.

Вызов serialize забавен. Понимаю, «нужно» все типы поддерживать, но не такой же ценой.

Насчёт осмысленности вызова md5 при целочисленных ключах вообще без комментариев. Это всё ради сохранения ручного порядка элементов что ли?

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

Ах да, и тестов нет. Для такого рода библиотек это критично.