Чем тебе не угодил хэш-массив? Думаю, просто для тебя это что-то новое и не знакомое, на самом деле логически он присутствует в любом языке программирования.
Ну ты же можешь описать класс так:


Это сообщение отредактировал(а) tishaishii - 2.2.2007, 04:17

Короче, вот тебе тот же пример, но в файлах и с некоторыми комментариями.
Чтобы испытать надо выполнить команду (в командной строке):

Это сообщение отредактировал(а) tishaishii - 2.2.2007, 04:13

Присоединённый файл ( Кол-во скачиваний: 23 )
 Class.zip 1,57 Kb

Тут ты что-то загнул. На заборе "В. Цой" написано, а за ним ничего нет.

Вот тебе пример с AUTOLOAD, чтоб ты поразбирался с "истинным удовольствием".

И где тут какая-то дребедень, которая там, у тебя в книжке написана? Плохая книжка.

Это сообщение отредактировал(а) tishaishii - 2.2.2007, 05:00

Хэш-таблица*  - это элемент языка программирования, являющийся особенностью реализации на конкретном языке программирования. Где написано, что использовать напрямую Ээлементы реализации" не рекомендуется - да в любой книжке, что посвящена объектно ориентированному программированию, а лучше, объектно-ориентированному проектированию   Очень логично, на самом деле. И авторы приводят массу доводов для этого.

Приходит на ум книжка Ф.Брукса "Мифический человеко-месяц", который в качестве правильного метода проектирования рекомендует работать отдельно с сущностью объектов, вне зависимоти от акциденции (реализации на конкретном языке).
И вот, в частности, та, что лежит у меня сейчас на столе ближе всего ко мне  

Дж.Рамбо. М.Блахо UML 2.0 Объектно ориентированное моделирование и разработка. 2-е изд. - СПб.: Питер, 2007. -- 544 с. ил.

Про твой пример: (я про AUTOLOAD)

И где здесь класс? Какова его концептуальная сущность? Где его методы? Каков его интерфейс? Вообще интересно, как ты трактуешь понятие "полиморфизм" на своем классе.  

Элемент программной реализации, который делает что-то "непонятно как" - это далеко не класс!  Представляешь, ты просишь собаку замяукать (вызвать метод, про который объект, порожденный от класса "собака", просто не знает)! Не знаю как у кого, а моя собака посмотрит при этом на меня, как на идиота. Заставить собаку мяукать - это абсурд, правда? Зачем же тогда так поступать со своими объектами?

А предстваляешь удивленные глаза начинающего программиста, которому этот код будет отдан в поддержку! Как говорит один мой знакомый: "Так объясни мне! Не могут же все быть такими умными как ты!".



Кстати, про AUTOLOD (и про "начальное определение свойств") написано в Advanced Perl Programming, Cookbook, perldoc 
perltoot - источники для тебя авторитетные? Для меня - да.  Предпринимается некоторая попытка достичь хотя бы иллюзии инкапсуляции для класса в Perl. 

---
*  В перле, кстати, не хэш-массив, а именно хэш-таблица. Т.е. элементы хэша хранятся не "друг за другом", а "каждый сам по себе". Или, по-другому, механизм, который определяет способ задания адреса  элемента для массива и адреса элемента для хэша - совершенно различен! Для массиива - последовательное хранение адресов, когда, адрес каждого элемента можно однозначно вычислить по номеру в массиве. Для хэша - некая функция, которая вычисляет адрес элемента по значению ключа. Именно поэтому хэши медленнее работают. Достаточно давно об этом где-то читал. Конкретно где, к сожалению не помню.



Это сообщение отредактировал(а) Zuzu - 2.2.2007, 11:59

Массивы предпочтительнее использовать там, где требуется последовательный перебор значений, хэши - для поиска конкретного значения (с этим они справляются гораздо быстрее)

Согласен с Zuzu. Объектная модель в Перле напоминает постоянно отпадающие при ходьбе костыли.

Перл 6 будет объектно-ориентированным языком. Собственно, из-за проблем с реализацией объектности при сохранении работоспособности более ранних программ мы ждем так долго  

А пока я почти не использую объекты в Перл.

Shaggie, я бы не был столь категоричным! Можно их (объекты в Perl) использовать. Естественно с некотрыми допущениями (Попробуй, кстати, это прикольно! Если что - можно обсудить либо в форуме либо в ЛС). Проблема в том, что эти "допущения" несколько нервируют, когда переходишь от проектирования к реализации - просто не получается математически точная реализация модели (математически точная - значит реализация должна делать то, что должна делать и не должна делать, то, что делать не должна - именно так)! Не удержусь, приведу цитату из Дж.Рамбо:

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


А про хэши и массивы - естественно разговор про "примерно однотипные задачи", например, скорость последовательного выбора всех элементов. Хороший пример - реализация свойств (если более более корректно - данных) объекта на в виде "приведенного" (blessed) хэша, а в виде "приведенного" массива, есть в Advanced Perl Programming.

Это сообщение отредактировал(а) Zuzu - 2.2.2007, 10:41

А я не категоричен  Объекты в Перл я не ипользую по той простой причине, что работаю в PHP. Перл - это мое большое увлечение. За пару дней до нового года купил кэмел бук (Programming Perl), просто так, для себя. Прочитал дважды, теперь всю работу в системе оптимизирую с помощью скриптов. Собираюсь бросать PHP, он уже кажется мне ограниченным и надуманным. Но до серьезных проектов не доходило, увы.


Такой вывод я делаю на основании прочитанного материала в вышеупомянутой книге, комментариев Ларри и содержании сайта perl6.ru
Необходимость насильно закрывать внутренние поля и методы, трудности с export, многозначность @ISA, постоянный контроль обращений к твоему пакету...


Перечитал тему... Я, похоже, и в самом деле чересчур категоричен  Это от недостатка опыта, прошу извинить.

Давай другими словами напишу, что ты делаешь. Ты меняешь поведение (метод) наследника путем изменения структуры данных (свойств) суперкласса. Пичем происходит это наэтапе выполнения.
Извини, уж не знаю, зачем для такой простой задачи нужна такая, мягко говоря, громозкая реализация.

Если тебе это реально надо что-то подобное (пример просто в голову не приходит - уж не знаю, в каких случаях это можно применить) - есть нормальные и формализованные решения, описанные, например, в книжке Гаммы  про шаблоны (patterns) проектирования.


Это сообщение отредактировал(а) Zuzu - 2.2.2007, 12:58

Я бы сказал, что если пытаться реализовать через массивы задачу, которую можно сделать через хэш, то (значительного) выигрыша по времени не будет (см. тесты).

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

Zuzu, я боюсь ты все таки не верно понял, о чем говорит tishaishii 

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

То что он привел пример где свойство описывается для объекта, то имхо не удачный пример, в присоединенном файлике как раз наоборот, все очень правильно, и красиво...

Хотя в другом я с тобой согласен, нету однотипности 
Если этот тип описания использовали изначально и как базовый класс для всех остальных,  то да, очень елегантное решение, но реальность такова, что его конструкция в действительности немного громоздкая, хотя не лишена некоторых прелестей... 
Я когда познакомился с tie тоже очень загорелся созданием своих типов, которые бы вели себя так, как мне нужно, даже создал регистронезависимый хеш и массив был у меня который при undef элементу удалял его, то есть всегда имел определенные значения, много чего было, но оно както не прижилось, вполне хватает сейчас стандартных возможностей языка...

А в плане свойств недавно сделал такую вещь, у меня в конфигураторе было так
$config->param('fff') - возвращает значение
$config->param('fff, 'new') - возвращает старое значение, присваивает новое 
но вспомнив про левосторонние функции сделал так в определении param

все больше не менял ничего
теперь можно вызыыать конфигуратор и так
$config->param('fff) = 'new';
все очень даж приятно выглядит...

конечно остается возможность напрямую обратиться к внутренностям $config, но я считаю что вполне достаточно педальки перед внутренним методом  Ну а если нужно, то пускай человек лезет, это его проблема... я честно предупредил "НЕ НАДО" 

amg, если мне память не изменяет, минимальный размер свертки для хэша в перле составляет 8 элементов.  В теории, по технологии создания хэша, адрес в свертке определяется по ключу (есть некоторая функция, которая ставит в соответсвие ключу адрес пары ключ-значение в памяти). Попробуй увеличить размер массива и хэша, например, по 1500 элементов и в качестве ключа хэша использовать что-то типа random(9999) x 5 для ключа, чтобы ключ был слегка подлинее. Подозреваю, что возрастет кол-во коллизий при определению адреса элемента по ключу в хэше.

Кстати, чтобы больше "напрячь" хэш по премени, можно попытаться извлекать элементы из него в порядке вставки (или в случайном порядке), а не в том порядке, который он, хэш, сам возвращает.  Можно случайным образом выбирать несколько элементов  n ключей и n номеров и сравнить время их выбора из массива и хэша. По документации - должно быть до 30% разницы в скорости выбора.

Хотя лично сам такими проблемами не заморачивался. Стараюсь по возможности минимизировать структуры данных в памяти. Там где нужен хэш (в частности для хранения неупорядоченного множества) исползьую хэш, там где важен порядок - массив. Наверно, банальную вещь сказал..

Nab, в приведенном примере (даже если он работает - проверить просто не было времени, а при прочтении, что он работает, для меня лично неочевидно), без переписывании Child, очень затруднено наследование свойств от класса Child (добавлене новых свойств, переопределение текущих свойств, например в классе SmallChild - наследник Child (да простят меня знатоки UML за текстовую, а не визуальную запись!):

Class () <|--- Child (+p2, +p3) <|--- SmallChild(+p2, +p4)

Т.е. в классе SmallChild должно быть три свойства: p2, p3, p4. Скорее всего, достаточно просто решается путем небольшой корректировки кода класса Child.

А вот с множественным неследованием от класса Child возникают серьезные проблемы. Там кода наколбасить придется очень много, чтобы все это работало нормально. Причем именно в конструкторах классах-потомков.

Про lvalue - спасибо, попробую. В каком Perl, это кстати, появилось? 

Это сообщение отредактировал(а) Zuzu - 5.2.2007, 11:01

Действительно, при увеличении длины ключей с 16 до 160 символов доступ к элементам хэша по ключам замедляется (примерно в 2 раза) и становится в 2-3 раза медленне, чем доступ к элементам массива по индексам (который, кстати, практически не замедляется при увеличении размера элементов).

Проверил и это. Документация не врет  Кстати, доступ к случайным элементам массива тоже раза в 2 медленнее, чем по-порядку.

Добавлено @ 15:26 
Похоже, тут я не прав. Два набора строковых данных, хранящихся в 2-х массивах или в 1-ом хэше, занимают одинаковое кол-во памяти. (Если смотреть по размеру файлов после Storable)


Это сообщение отредактировал(а) amg - 5.2.2007, 16:00

Zuzu, а если сделать такой хэш, который не поместится на все твою оперативку, винты, флэшки, DVDшки  и всё прочее, что тогда делать? А нечего тогда такой хэш делать, реально для этого есть СУБД или искать способы оптимизации или писать в машинных кодах. Что-то это, по-моему, перегиб уже пошёл.


А я создал ради прикола или лени с помощью String::Approx  и Text::Soundex класс с AUTLOAD со свойствами и методами, причём имя свойства или метода можно задавать при использовании как угодно, т.к. находится самое похожее по названию из имеющихся, это чтобы для разгильдяев, чтобы в именах методов и свойств можно было ошибаться. Ну это ни куда не годится, просто можно программировать и обезьяне чтобы можно было.

Ну вроде как:


Это сообщение отредактировал(а) tishaishii - 5.2.2007, 17:51

tishaishii, пожалуйста, давай останемся в рамках темы, т.е. обсуждать именно аспекты ООП и его реализации а Перл.

Про tie - то подсказал, спасибо. Может я чего не понимаю. Не сочти за труд, покажи, пожалуйста, как на твоем классе реализовать такую простейшую модель, как та, что изображена на рисунке. Там изображено множественное наследование свойств. Класс Child должен наследовать свойства p1, p2, p3, p4. Если воспользоваться рекомендациями из документации по Перл, решается примерно так:



Извините, если что не так - набивал код прамо в форум.

Это сообщение отредактировал(а) Zuzu - 5.2.2007, 18:26

Присоединённый файл ( Кол-во скачиваний: 17 )
 simple.gif 1,47 Kb

Ну так и супер.... 
Я такой состряпал для имен модулей, у меня теперь есть:

use_similar 'DATA_Dumper';
подгрузка модуля... на ходу...
аналогична таким
use_similar 'DATA::Dumper';
use_similar 'DataDumper';
....

там несколько режимов совпадения 
и работает вполне корректно...

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

кстати мой конфиг тоже имеет AUTOLOAD и тоже левосторонний 

так что и 

$config->fff = 'new'; 

тоже катит 

А вообще это уже не в тему, точно Zuzu заметил 


Zuzu, множественное наследование вообще гадость редкостная, в особенности  в связке с AUTOLOAD у родителей 
Возможно ктото его и использует активно, но я стараюсь держаться от него подальше, хотя и использую несколько маодулей со CPAN в которых оно используется...

Насколько я знаю красивого решения оно не имеет ни в каком мне известном языке... (могу ошибаться).
Ну а в перл, думаю лучше всего использовать агрегацию...