А по теме, поднятой мной. 

(см. http://forum.vingrad.ru/topic-132126.html )

Статья меня откровенно повеселила, Рад, что вас повеселила тоже.  

ИМХО, только две вещи автор отметил правильно. Все остальное - от (скорее всего) природной злобы автора и непонимания собственно Perl, его (Perl) назначения и места в мире языков программирования. Итак, две вещи:

1. Отсутствие нормальной (с точки зрения классического определения) поддержки ООП - объектно ориентированного программирования. Конечно, вы можете возразить, что на Perl все можно написать. Однако хочется, чтобы все это уже было внутри языка. Это лично меня приводит к некоторому внутренниему дискомфорту, когда пишешь на perl. А это, собственно, основной язык, которым я пользуюсь.

2. Неочевидность некоторых конструкций для (особенно) начинающего программиста-читателя. Неоднократно было подмечено. "Старт" проходит достаточно тяжело. Зато затем - почти все нормально. Из забавных фактов по этому поводу, хочется отметить, что одна моя знакомая, чтобы облегчить понимание приема параметров в процедуру, предложила назвать переменную @_ "собака с хвостом". Типа "а сейчас к нам пришла собака с хвостом".

Вот так.


Это сообщение отредактировал(а) Zuzu - 26.1.2007, 13:16

Zuzu, а какую-такую "нормальную" поддрежку ООП ты хотел?
В Perl можно создавать пакеты, классы, собственно, объекты, есть множественное наследование, делигирование, возможность обращения к структуре класса-предка, можно использовать локальные переменные, есть механизм связывания (tie). Вообще, чего нет изначально в интерпретаторе-компиляторе, давно уже написано в модулях и прагмах или можно написать. Чего ещё требуется?

Добавлено @ 10:46 
Я тут вот начал-таки читать "статью" и уже с самого начала она мне стала нравиться, большую роль в это проишествии сыграла первая же фраза "Статья посвящена популярному языку программирования PERL". Ну, коли он популярный, значит, его много кто использует, а он решил выявить и представить какие-то недостатки, которые, фактически, если даже есть, то те, кто пользуется языком (а он "популярный"), готовы с этими недостатками смириться и продолжают пользоваться плохим языком Perl.

Еще раз повторю, руками можно написать все. Речь идет о поддержке именно на уровне языка.

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

СкАжите: хочешь строгости - используй use fields Отвечу - не работает это в случае множественного наследования. В документации об этом написано (собственно, и так понятно, почему не работает).

Понятно, что вы (как собственно, и классики, типа Гаммы (одна из книг отсюда: http://ooad.asf.ru/Files.aspx)) можите возразить: не используй множественное наследование (а лучше и наследование вообще) - а используй композицию (или, если быть более точным, агрегацию (aggregation)). Отвечу: иногда хочется. Т.к. проектировать и читать такие программы приятнее и проще. Приведу пример из своих последних новогодних экспериментов (на уровне посленовогоднего бреда): 

(абстрактное) животное (есть имя и цвет)  -> кошка (есть имя и цвет, умеет мяукать)
(абстрактное) животное (есть имя и цвет) -> рыба (есть имя и цвет, умеет плавать)
кошка + рыба -> кошкарыба (есть имя и цвет, умеет и плавать и мяукать)

Ну и по мелочи. На уровне мелкого дискомфорта.

2. Следствие отсутсвия типизации - отстутсвие такого типа данных, как "объект определенного класса".  То, по поводу чего автор статьи аж весь изошелся.  Видете-ли (пред)компилятор не проверяет наличие/отсутсвие описанных методов (и процедур, собственно), и ошибка возникает на этапе выполнения. Собственно, понятно. Нет типизации - сам за всем следи. Плата за гибкость.

3. Отсуствие внутренних (используемых только внутри объекта) методов. Все можно вызвать снаружи. Опять - нарушение инкапсуляции. Решается административными действиями, путем описания, что все, что начинается с _ (подчеркивания) - внутренний метод. И, дополнительно, на уровне контроллера приложения (Aplication Controller см: http://ooad.asf.ru/Patterns_title.aspx?IdKat=9), чтобы обеспечить внешнюю безопасность, чтобы любой пользователь (не программист!) не смог вызвать внутренний метод объекта.


Это сообщение отредактировал(а) Zuzu - 18.1.2007, 14:39

Zuzu, ждём Perl6  можно и тут глянуть, с чем предстоит... думаю тебе понравится ;)

Добавлено @ 18:26 
тут

Zuzu, давай в приват, что ли. Поговорим на тему ООП.
Мне не понятно, почему ты говоришь, что у объекта в Perl нет свойств, т.к. свойства обычно хранятся в хэш-массиве, а если ты под свойствами имеешь в виду синтаксическое их написание без фигурных скобок, так это всего-то особенность языка (может, скажешь, что тебя и $ или % тяготит?). Таак, ну в Delphi, там можно указывать методы обработки работы со свойствами типа getter и setter. Это в Perl решается с помощью встроенной функции tie.
Какой-такой геморрой со множественным наследованием? На счёт инкапсуляции. Таак. Ну, вот её-то и нету. Да, только, принципиально, она нужна? Объявление типа private беспокоит тех, кто борется за свои авторские права, а Perl создан как Free и OpenSource - идеология такая. Я принципиально-против типов данных в Perl - тоже нарушает идеологию, т.к. Perl создавался для манипуляции структурами данных, а про типы думать не надо.

Не, ну ты мне приведи задачу, которую не возможно решить с помощью языка.
[hr]
nitr, про Perl6 уже обсуждали в другой теме.

Это сообщение отредактировал(а) tishaishii - 18.1.2007, 20:07

Zuzu, к стати, я вспомнил. Функции и свойства вроде private можно организовать с помощью встроенной функции caller и при определённом методе AUTOLOAD в классе.

tishaishii, отвечу лучше здесь. Про tie ты ведь мне идею подсказал, спасибо. Может еще у кого какие мысли будут.

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

Простой пример - поле (строки) таблицы базы данных, для которого определено NOT NULL, а ему пытаются присвоить значение NULL. Что произойдет? DBMS выругается и неверного значения (в общем случае, строке) не присвоит!

2. За идею про tie и связывание свойств почитаю, спасибо. Но, ИМХО, очень уж тяжелая конструкция получается.

3. Privte методы реально упростили бы жизнь с точки зрения внешней безопасности приложения (см. п. 3 моего предыдущего топика). 

Напрягает больше не то, что нужно описывать (на уровне if или в самом объекте), какие из его методов можно вызывать снаружи (из web-интерфейса, например), а то, что  потом все это нужно проверять. Объект-то про свою целостность должен знать сам! А если этот объект участвует во множественном наследовании - всех "родителей" приходится обходить "вручную", чтобы все это выяснить. Так что по поводу Private не нужно путать теплое с мягким! К авторским правам оно имеет такое же отношение, как морская свинка к морю.

4. Нет инкапсуляции - нет поддержки ООП (ООП есть инкапсуляция, наследование, полиморфизм). Извини, элементарная математическая логика. Все выражение истино тогда и только тогда, когда все его "слагаемые" истины. У Вирта, кажется это есть. Может у кого ссылка есть на библиотеку с книжками Вирта? Поделитесь ссылочкой.

5. Про AUTOLOD и "автоматическую генерацию методов", если ты внимательно почитаешь Advanced Perl Programming (и в Cookbook, кажется, написано тоже), там есть один прикол. 

До вызова AUTOLOAD необходимо определить (присвоить значение) элементу хэша. При отсутствии элемента инициируется исключение (die). И, собственно, понятно, почему. Нечего всякую ерунду для для объекта вызывать! При обычном наследовании еще можно определить (инициировать) значения элементов хэша путем обращения к процедуре инициализации своего суперкласса ($self->SUPER::_init() - как вариант). При множественном наследовании это не прокатит - нужно обходить всех "вручную". 

6. Про типы данных - ты зря! Но это мое личное мнение. Я бы не отказался.

7. Написать можно что угодно и на чем угодно. Хоть в машинных кодах наколбасить. Особенно если воспользоваться "абстракцией потенциальной осуществимости" из математики (типа если все живем вечно и кормить никого не нужно - тогда напишем любую программу). Я не хочу "хаять Перл". Он меня кормит! Просто есть вещи, которых "жалко что в Перл нет".

Вообще, сам на досуге "поиграйся" с поддержкой ООП в перле и попробуй реализовать классические вещи (хотя бы на уровне модели, когда результатом $aCat->speak просто является print "Meauuuu!!!\n"), которые описаны в литературе по ОО программированию (а лучше по ОО проектированию). Хотя бы с наследованием  свойств и методов и их, (свойств и методов) полиморфизмом - раз уж выяснили, что инкапсуляции нет  Лично мне это упражнение доставило в свое время истинное удовольствие.

P.S. Господа модераторы! Подскажите тему, куда это все перенести! Извиняюсь за offtopic.

Короче, прошу прощения, у меня не много времени на ответ.
Вот ты мне приведи задачу, которую не возможно решить на Perl.

Вынес всё, что касается ООП в отдельную тему. Здесь можно продолжить обсуждение.

Zuzu, ну у меня реальные вещи в голове не укладываются пока без ООП. Так что играюсь уже с этим ООП в Perl года 2-2,5 и говорил тебе всё это не по-наслышке.
А что сложного там в tie - это не в курсе. На худой конец есть уже готовые модули (типа Tie::Hash... - http://search.cpan.org/search?query=Tie%3A...mp;mode=module).

Ну вот тебе готовый код, например, для скаляра (можно использовать как свойство в классе):


а вот пример его применения:


Если есть вопросы как работает - пиши.

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

tishaishii, спасибо за пример. Посмотрел код. Забавно. 

Лично я фразы типа +$${$_[0]}{-setter}(@_) понимаю только после вдумчивого второго прочтения... Наверно, возраст, сказывается... Но все-таки понимаю, что радует! 

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

И собственно, "мысли по коду".

Во-первых, лично я считаю, что класс (Class) должен сам знать о свойствах объектов, которые от него порождены и переписывать их (свойства) во время создания экземпляра (объекта) не считаю правильным. Нарушается идея "представления объекта, как черного ящика". Как следствие, если ты вдруг нашел ошибку в коде какого-то setter-а, например, то тебе придется его выискивать и исправлять ошибку во всем своем коде, а не "просто поменять в классе". А если твой класс используется в качестве компонента другой системы? Радости от такого программирования и дальнейшей поддержки кода очень мало.

И еще, ИМХО. В нотации UML (по крайней мере UML 1.4) принято обозначать "закрытые" свойства с - в начале (-privateName), а "открытые" с + (+publicName). Т.к. в perl нет такого понятия как "закрытое свойство" на уровне языка, лично я предпочитаю на "смешивать понятия", а использовать принятые в Perl соглашения. А именно, если имя начинается с _ - это "внутренняя штучка" объекта (_name) . Иначе - "открытая штучка" (name). 



Это сообщение отредактировал(а) Zuzu - 25.1.2007, 15:27

Ну, пользуясь  таким Class, ты можешь породить класс Child:

Использование:


Добавлено @ 19:27 
Если хочешь обрабатывать аргументы в Child::new:


Это сообщение отредактировал(а) tishaishii - 25.1.2007, 19:24

Короче, ты уж определись, нужен тебе Perl 5.8, али - нет?
Он помогает легко решать многие проблемы, которые не так легко решить в друших языках (кроме Refal и Prolog, наверное). Но есть куча модулей на search.cpan.org, которые тебе чрезвычайно помогут. Возможно переписывание операторов (как в Ц). Возможно подключение АктивИкс-объектов - а их ты можешь создать сам, а вот такой простой язык с ними использовать очень удобно. Какие ещё-там проблемы с ООП - говори - предложу подходящее решение.

Добавлено @ 23:07 
Таак, ещё, про private тебе надо приводить пример про caller, AUTOLOAD и @AUTOLOAD?
Это, как всегда, просто. При вызове метода, всего-то, надо распознать модуль, вызывающий метод. Для Perl 5.8 - это СЛОЖНЕЙШАЯ ЗАДАЧА. ))))

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


      
Опять-двадцать пять! Мы, видимо, просто говорим на разных языках и тебя сбило с толку замечание о том, что необходимо будет менять код в разных местах при нахождении ошибки... И чем твой код концептуально отличается от того, что было в предыдущем варианте? Да ничем! Ты определяешь (инициализируешь) структуру данных (вместе с getterom!) на этапе выполнения а не на этапе описания. Да еще через связывание с использованием tie, да еще передав ее (структуру) SUPER-классу... Что по мне, то я готов смириться с тем, что "хэш объекта" - вещь, которую "руками не трогать" (на уровне административных мер, как вариант, при работе в команде), а для определения (читай - "описания", которое можно понять даже не запуская программу, прочитав при этом код самого класса, а не "шарашась по всему коду") использовать что-то полегче типа трививального, рекомендованного в стандартной документаци по Perl.



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

- Через год можно будет ее понять, даже не вникая в суть проблемы.
- Реализовывать и поддерживать можно будет отдать программисту, который "с неба звезд не хватает".
- Вообще меньше загружен мозг при реализации, если пишешь код сам. Нужно просто "тюкать по клавишам" или, как вариант, сконцентрироваться на аспектах реализации, решая при этом одну частную проблему, а про общую логику "всего комплекса" можно просто на время забыть. Обо всем этом позаботились раньше при проектировании, тестировании и проверке модели на этапе проектирования. Можно даже попытаться доказать правильность алгоритма аналитически (т.е. без реализации, не запуская) - сам алгоритм-то меньше получается!

Что-то стало смахивать на "религиозные войны"... А так вообще (скажу, наверно, банальную мысль) я придерживаюсь мнения, что каждый может все писать так, как ему удобнее. С учетом "административных требований" команды, в которой работаещь, конечно.

Я указал параметры на этапе описания и с чего ты там взял про "выполнение", когда при описании модуля я использовал другой модуль и описал первый. 
Ты вообще в курсе, что такое "SUPER::new"? Это аналог "super" в Java. И ты хочешь ещё бороться с тем, что ООП в Java плохое? И что означает восклицание ? Я не в полне тебя понял, что зазорного-такого в связывании (тем более через tie), когда я передавал структуру супер-классу и что в этом может быть такого нехорошего?
По-моему, ты просто не до конца понимаешь примера, что я написал.
Чувствую, у тебя есть психологическая проблема: ты озлоблен, причём на вещь, которая существует только в твоём воображении - на язык программирования.

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


Это сообщение отредактировал(а) 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 в которых оно используется...

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

Не знаю, на каком языке ты говоришь, Nab, но множественное наследование - вполне ясная вещьчь: кто последний, тот и прав.

Т.е. ты утверждаешь, что если есть метод m1() в классе Father и Mather, Child - их наследник (от Father Mother), то выполнится код от Mother?   Или приведенный ниже код выдаст результат "M1 from Mother", так?





Ты заблуждаешься! В перле - другие правила поиска методов. Описаны правила, в частности, в Cookbook. Будет "M1 from Father". Или в записи use base qw/Father Mother/ ты считаешь Father последним?



Это сообщение отредактировал(а) Zuzu - 7.2.2007, 09:49

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

Ну я в параметры base::import  в Child местами попереставлял, получил, что работает "кто первый, тот и прав". Ну так и что же в этом мудрёного?

tishaishii.  То, что я описал - очевидно. И следует непосредственно из оригинальной документации по Perl. Там написано все очень четко.

Правило "Кто первый, тот и прав" - тоже не катит.

Ниже - простейший код. Какой метод m1 снаследует Child в этом случае? По твоему предположению - выходит от Mother -  это неверно.



Спросишь, к чему это я? 

Во-первых, лично я привык понимать, что делает программа без ее запуска на выполнение. Очень часто это спасало, когда нужно было быстро исправить ошибку на "живом" проекте, который реально работает. А на "исправление по всем правилам" - перенос всего кода и данных на площадку поддержки, исправление и отладка там, перенос отлаженного кода обратно на "реальный проект" - просто заказчик не дает времени.
А во-вторых, просто хочется увидеть код твоего класса с геттерами-сеттерами через tie для моей простейшей модели с множественным наследованием. Той, что я рисовал в виде диаграмки. Я свой код написал прямо в форум буквально за пару минут.
 

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

Nab, я посмотрел lvalue применительно к методам класса  (как к setter'ам для свойств объекта). Мне не понравилось. Ожидал чуда, а они работают именно как lvalue  Т.е. меняют значение переменной, указанной в return процедуры.

Соответсвенно, никакой радости в виде проверки корректности данных (внутри процедуры-метода) мы не получаем - работаем-то внутри процедуры со старыми, предыдущими значениями. Короче, скорее всего, использовать не буду. Смысла не вижу.

Несколько сумбурно получилось. Если что непонятно написал - говори, приведу пример кода.


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

Zuzu, я думаю тут видно... 

тут первый Father

меняем и получаем )




tishaishii, прав с этим правилом ;)

nitr, вопрос был не в том, как сделать, чтобы вызвался "M1 form Mother", а в том, какой метод реально вызовется без внесения изменения в код.  

Если (для моего последнего примера кода) пользоваться правилом "Кто первый, то прав", должет вызваться "M1 from Mother", а это не так. Думаю, не открою тайну, если скажу, что результат будет "M1 from Class"  т.е. Child при такой записи наследует метод от своего "самого базового" класса. Это, с какой-то стороны, логично, но без прочтения документации неочевидно.



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

Все, до меня наконец-то дошло, почему концептуально все работает именно так. 

tishaishii, ты абсолютно прав! Работает правило "Кто первый тот  и прав". Все абсолютно логично. Просто нужно рассматривать классы, как некую "конечную сущность". Действует правило, аналогичное правилу написния UML-диаграмм, которое, если просто, гласит: что если чего-то не написано, это еще не значит, что его нет.

В моем примере у класса Father уже есть метод m1(), несмотря, на то, что в самом классе его нет. Father его снаследовал от Class! 

По правилу "Кто первый, тот и прав"  - первый Father. У него есть снаследованный метод m1(). Именно он и наследуется.

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

приводи

Nab, пример кода с lvalue





Результат:

Стыдно мне, таки нифига оно не работает 

Плохо проверял однако  И не до конца разобрался 

Приношу всем извенения, за то что ввел в заблуждение народ....

Zuzu, по-моему, то как раз то, чего можно ожидать от использования lvalue. WYSIWYG кажется это называется...
Nab, за что извиняешься? Мне вот кажется, что ты прав.

Shaggie, я ожидал от lvalue чуда в том смысле, что надеялся, что оно сначала (грубо говоря, перед первой строкой кода процедуры) присвоит значение переменной, а уже внутри процедуры-метода можно будет использоваться именно это, новое значение. По аналогии с передачей параметров внутрь процедуры.

При проверке выяснилось, что не так (см. пример кода).

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

Т.е. ты нарочно схимичил и не переписал метод m1 для Father, чтобы с первого взгляда казалось, что вызывается не Father::m1, а Class::m1? Не получилось у тебя запутать:)))

И чего такого "чудесного" от lvalue ты ожидал? Механизм как механизм, а ты ждал "чудесный" механизм? Ну и используй значение, кто не даёт?

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

Это сообщение отредактировал(а) tishaishii - 11.2.2007, 08:30

Мои пять копеек.

Zuzu где-то отметил трудности с созданием закрытых методов класса (по типу private). Рискуя изобрести очередную вариацию велосипеда, я все же решился провести некоторые опыты и на личном примере убедиться в истинности либо ложности данного утверждения. Для примера Zuzu предлагал создать класс Кошка и объявить в нем метод Говорить... Ок, так и поступим.

У нас есть кошка Тася, которая говорит "Мяу". Вопрос - метод закрытый? Ну, как сказать... Например, имеет силу такой вот код:

То есть объект не создан, память не выделена. Мяукает какая-то совсем другая кошка, не та, которую я позвал...
Была недавно тема о том, как определить, объект ли передан в функцию. Самый простой способ:

И теперь некая безымянная кошка мяукать не может. Однако... say - это просто функция по большому счету. То есть имеет смысл такой вот код:

И если не будет той проверочной строчки в say, то любой волк в кошачьей шкуре сможет сказать "Мяу". А теперь вылезает ошибка, так как параметры в функцию не передаются, и shift ругается на unitialized value. Исправляем:

И только потом до меня дошло, что проверка на "=" сработает на ЛЮБОМ объекте, передаваемом в функцию! Для проверки я создал пакет Dog, в нем метод call, совершенно аналогичный такому же в Cat. И теперь:

И пес Пират мяукает по-кошачьи! Прелестно... но надо править.

Вот это получилось похоже на закрытый метод.

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

Это мой первый опыт объектного программирования в Перл, поэтому просьба комментировать если оказался не прав.

И наверняка существуют модули под это дело...

Shaggie,

для этого есть Class::ISA(::self_and_super_path как пример)
там можно и смотреть...

может кто скажет, что тут имеете ввиду под "закрытыми методами класса (по типу private)"?  А то неувязочка в моей голове...

С этого и начнем 

проверка на принадлежность определенному классу делается проще всего:


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

Второе, private метод это метод который в принципе не виден и не может быть вызван, ВООБЩЕ.


А реализовывается он при необходимости таким способом:



все , метод say может быть вызван только внутри ФАЙЛА, содержащего пакет и нигде более... 
даж потомки не смогут, если они определены в другом файле.

Если как в Вашем примере, то они могут звать друг друга как угодно...



Это сообщение отредактировал(а) Nab - 12.2.2007, 13:46

А если файл Dog.pm
сделать таким:


то отраютают  и gav и gav_gav.

но во втором случае собака всеже залает 

Nab, спасибо.

Проверка на принадлежность определенному классу - действительно удобно. То, что мне и было нужно.

Восстанавливаю затертое.

Да, появилось замыкание. Да, метод say теперь является ссылкой на функцию, вызываемой из метода gav, и теперь никто не может обратиться к методу say... Но работает такой код:

В результате к ЗАКРЫТОМУ методу say можно обратиться через ОТКРЫТЫЙ метод gav. То есть в любом случае закрытость методов от использования потомками/простым кодом не обеспечивается.

Это сообщение отредактировал(а) Shaggie - 13.2.2007, 08:17

Shaggie, не верный вывод....
gav сделан как обертка, только для демонстрации. Не обязательно он нужен, зато метод сохраненный в преременной $say не доступен нигде кроме пакета в котором он определен, то есть если не делать gav, то это реально приватный метод получается...

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

Так что разница есть и существенная...

Nab, не понимаю:

Да уж , это называеться найди 10 отличий...


Это не просто определение функции после которой не нужно ставить точку с запятой, это операция присваивания...

И верно будет так:


И вообще Shaggie, боюсь нас не верно поймут, потому как эта теме вынесена в прикрепленные, именно для обсуждения тонкостей и нюансов, а также некоторых неочевидных вещей. А те вопросы которые мы сейчас обсуждаем описаны в большинстве учебников по Перл.

Может стоит задавать непонятные вопросы в обычном форуме, а эту тему оставить для всяких "извращенцев от перла" 

http://search.cpan.org/~mschwern/Class-Fie.../lib/private.pm

tishaishii, спасибо. Насколько я понял, модуль private применяет в качестве основы обеспечения закрытости доступа модули Class::Fields::Attribs (обеспечивающий имена констант) и Class::Fields::Fuxor (обеспечивающий функции установки и проверки прав доступа), а от себя проверяет наличие подчеркивания перед именем закрытого метода. Этакий use strict для объектного программирования  

Nab, код скопирован из твоего примера  Насчет отличий - понятно объяснил, спасибо. Действительно глупая ошибка, я мог бы и сам заметить  Насчет закрытости методов - увы, остаюсь при своем мнении: этого нет в языке, но несложно реализовать его возможностями (что демонстрируют имеющиеся модули. Рекомендую к изучению, они действительно могут обеспечить поддержку объектов в Перл).

Всем спасибо!  

Это сообщение отредактировал(а) tishaishii - 15.2.2007, 07:23

Нашел книжку, что давно хотел почитать.

Damian Conway: Object Oriented Perl 

Отсюда:
http://www.progteam.com/liter/?teh=Perl

Книжка на английском языке. Статус ее (бесплатная, платная, ворованная) - непонятен. По крайней мере, я нигде не нашел описания статуса.

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

Чесно говоря недавно сталкнулся с ООП в перле, более сложной и непонятной схемы не видел (я сравниваю с С++ и С#).  Хотя возможно это и к лучшему...

Это сообщение отредактировал(а) stan777 - 19.2.2007, 00:07

Что, собственно, не понятно было?
Удивило bless? Ну так new, в принципе, по же самое делает.

stan777, было бы интересно сравнить на простых примерах, например реализацию парадигм ОО Программирования в C# и perl. Если тебе интересно, конечно, приведи простенькие примеры.

А еще лучше - подготовь маленькую диаграмку (в UML, например) того механизма, который ты хотел бы видеть в Perl и реализацию этого на C#. Я думаю, не мне одному будет интересно поразбираться. 

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

А что там сравнивать-то? 1:1.
ООП, по-моему, имеет единую идеологию.
В конце-концов, я не в полне понимаю выражения "на уровне компилляции" и "на уровне выполнения". Всё равно, в итоге, происходит сравнение и всякие "если", даже, если это не было скомпилировано. Другое дело - скорость работы.

Довольно интересная разработка наших зарубежных товарищей — Moose
это, конечно, если пользоваться не "читсым" Perl, а уже доп. модулями, чем, с позволения сказать, Perl и силен...

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

Многим проектам вообще приходится писать с "нуля".
А Moose ещё надопоковырять, вдруг есть "затыки"  , которые ну во многих поектах существуют...

Этоть Moose делается за 2 минуты. И никакого особого смысла в реальном проекте делать эти 2 минуты смысла не вижу.

Вообще, тема private, public и protected противоречит идеологии Perl. Perl - проект opensource, а private и protected - это предрассудки.

Private и protected - не предрассудки, и уж тем более они никоим образом не противоречат идеологии свободного ПО. Это гигантское подспорье при проектировании и реализации крупного проекта. То, что перл не рассчитан на их использование, ещё не значит, что такие полезные концепции программированя можно объявлять первородным злом. У приверженцев PHP до 5 версии, вон, пространств имён не было, так они же не стремились откреститься от них, как от чумы, а признали несовершенность используемого языка. Более того, постепенно латают погрешность.

Кстати, 6 перл потому и творят так долго, что пытаются сделать совершенно объектным языком. А где объекты - там и права доступа. Посмотрим, насколько это будет противоречить духу opensource...

Если тебе не охота, то и не вызывай private и protected функции, а если сильно нада, то бери что хош. private и protected нужны только, чтобы защитить авторские права. При чём здесь "крупный" или "мелкий" проект? Ты не в полне понимает идеологию opensource.

Private и protected - средство защиты авторских прав? Это что-то новенькое...