>> По коллекции на каждый тип объекта? Шутить изволите? :) Почему в конструктор не передать ссылку на функцию или ещё как?
— Шутить, нет :) Я бы, пожалуй, все таки делал специализации, само собой, в умеренных количествах.
На счет предложения с конструктором — тоже неплохая идея. На сколько я понимаю, то в общем виде предложение выглядит как:
«Сделать IoC для функции getHash()»?
>> Почему для объектов всегда используется spl_object_hash? А если у меня два объекта считаются равными, если их id совпадает?
— Это прикладная логика. Наследуйте карту и реализуйте getHash().
>> Зачем для строк вычислять md5? Похапэшные массивы — и так хэштаблицы, не нужно вычислять хэши на двух уровнях. Только память и вычислительные ресурсы впустую расходуются.
— Действительно как-то не подумал. Есть только небольшой вопрос: что будет, если не преобразовывать в md5 достаточно длинную строку? Например, в несколько десятков килобайт? Если это не страшно, то действительно есть смысл переделать.
>> Вызов serialize забавен. Понимаю, «нужно» все типы поддерживать, но не такой же ценой.
— В точку, «нужно». Более элегантного способа не нашел. Предложите что-нибудь?
>> Ах да, и тестов нет. Для такого рода библиотек это критично.
— Тесты действительно нужно разработать. Займусь этим.
Теперь о вопросах работы с фильтрацией, сортировкой и т. д.
Я считаю, что отсутствие данных функций есть моя вина. Я должен был их включить в пакет, но не включил на текущий момент. Думаю, что их наличие существенно увеличит полезность и привлекательность пакета. Я займусь этим в будущем. На текущий момент был собран минимальный функционал, который позволяет работать.
На деревья смотрю отлично, но боюсь, что сейчас у меня на это не хватит знаний.
Другими словами, буду этим заниматься, но быстрых результатов дать не получится.
Если бы кто-то реализовал эти интерфейсы в качестве PECL модулей, я уверен, что работали бы они гораздо быстрее и доверия к ним было бы больше. Собственно, писал об этом в конце статьи.
На первый взгляд для реализации итерации путем использования foreach() достаточно реализовать интерфейс Iterator или его производные (любой наследник Traversable).
foreach ($list as $k=>$v) {...}
Так и планировалось сделать. Но на этапе анализа вылез подводный камень — foreach() неадекватно реагирует на ключ в виде объекта.
Исходя из этого я сделал единый вариант для всех коллекций, оставляя возможность реализовывать интерфейсы итераторов на более низких уровнях.
— Шутить, нет :) Я бы, пожалуй, все таки делал специализации, само собой, в умеренных количествах.
На счет предложения с конструктором — тоже неплохая идея. На сколько я понимаю, то в общем виде предложение выглядит как:
«Сделать IoC для функции getHash()»?
— Это прикладная логика. Наследуйте карту и реализуйте getHash().
>> Зачем для строк вычислять md5? Похапэшные массивы — и так хэштаблицы, не нужно вычислять хэши на двух уровнях. Только память и вычислительные ресурсы впустую расходуются.
— Действительно как-то не подумал. Есть только небольшой вопрос: что будет, если не преобразовывать в md5 достаточно длинную строку? Например, в несколько десятков килобайт? Если это не страшно, то действительно есть смысл переделать.
>> Вызов serialize забавен. Понимаю, «нужно» все типы поддерживать, но не такой же ценой.
— В точку, «нужно». Более элегантного способа не нашел. Предложите что-нибудь?
>> Ах да, и тестов нет. Для такого рода библиотек это критично.
— Тесты действительно нужно разработать. Займусь этим.
Теперь о вопросах работы с фильтрацией, сортировкой и т. д.
Я считаю, что отсутствие данных функций есть моя вина. Я должен был их включить в пакет, но не включил на текущий момент. Думаю, что их наличие существенно увеличит полезность и привлекательность пакета. Я займусь этим в будущем. На текущий момент был собран минимальный функционал, который позволяет работать.
Другими словами, буду этим заниматься, но быстрых результатов дать не получится.
Если бы кто-то реализовал эти интерфейсы в качестве PECL модулей, я уверен, что работали бы они гораздо быстрее и доверия к ним было бы больше. Собственно, писал об этом в конце статьи.
Данная ситуация может осложниться, если Unit не имеет уникально идентифицирующего его строкового или числового свойства.
На первый взгляд для реализации итерации путем использования foreach() достаточно реализовать интерфейс Iterator или его производные (любой наследник Traversable).
Так и планировалось сделать. Но на этапе анализа вылез подводный камень — foreach() неадекватно реагирует на ключ в виде объекта.
Исходя из этого я сделал единый вариант для всех коллекций, оставляя возможность реализовывать интерфейсы итераторов на более низких уровнях.
Если речь идет о интерфейсе Set и его реализации UniqueStore, то у SplObjectStorage нет встроенного контроля типов объектов.
Опять же не забывайте о человеческом факторе, можно элементарно забыть поставить проверку.
На практике важным моментом оказалась терминология. Больше не нужно говорить «сделай вот как вчера или как в том самом месте...».
Как показала практика — быстрое извлечение по ключу не говорит о том, что ключ не должен быть объектом.