В целом, тема очень широкая, и появились еще дополнительные вопросы... Вообще конечно, кое-что уже было разъяснено ;) однако я сам не с того конца сформулировал вопрос, поэтому и не получил все ответы на него...

В целом получится может даже убить два зайца...

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

P.S. В дополнение, также пока не совсем понял как лучше работать с директориями(пакетами), куда можно объеденить несколько классов, попытаюсь изобразить более визуально

./myScript.pl - <корневой скрипт>
./myClasses/... - пакет, где находятся классы, допустим
    ./myClasses/classesForDB/...
    ./myClasses/classesForFiles/...
    ./myInterfaces/....
./myUtils/... - также содержатся какие-то классы
./myModules/... - просто модули
./files/... - пакет просто для каких-то конфигов, xml-файлов, или еще чего-нить
...

Для знатока явы, я думаю понятно, что я хотел спросить про пакеты и подпакеты 

> чтоб допустим этот класс, являлся лишь полем какого-то другого класса

создаешь переменную в классе и этой переменной присваиваешь класс, т.к. класс в перле это всего лишь blessed ссылка (или array, ...)

> хотелось также затронуть момент переопределения метода, 

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

другое дело если надо в классе переопределить встроенный в перл метод -- в начале класса надо объявить эту функцию, например переопределение split:
use subs qw(split);
а уже ниже её описать.
экспортировать такую функцию не советую, путь живёт в пространстве имен только этого класса

> побольше функциональных действий в самом конструкторе...

в конструкторе можно делать что угодно, это самая обычная функция, которую и обозвать можно как угодно, например в Tk принято конструктору давать имя класса, хотя наиболее частый вариант -- это new

> как лучше работать с директориями(пакетами), куда можно объеденить несколько классов

создать для них каталог, например QQQ, и потом подключать их как
use QQQ::модуль1;
use QQQ::модуль2;

но и названия пакетов внутри тоже должны быть приведены к этому виду:
package QQQ::пакет1;
use 5.008;
use strict;

use QQQ::модуль2;
...

ЗЫ посмотри любой каталог, где лежат модули перла

Все же не совсем понял, а именно

use QQQ::модуль1;
package QQQ::пакет1;
use QQQ::модуль2;

тривиальный пример

есть два модуля: util.pm и work.pm, что и где должно прописатся чтобы можно было работать при структуре

./mainScript.pl
./modules/util.pm
./modules/work.pm

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

Пример конечно не плохой, но уж слишком "на пальцах" 

Хм...

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

модуль



соотв в самом скрипте достаточно подключить его use modules::printDatas, а для вызова процедуры достаточно PrintHeader допустим, но здесь у меня возник еще один вопрос. В модуле я ручками прописываю     push @EXPORT , '&PrintHeader';, но если уже есть хотелось бы, чтоб это выполнялось для всех процедур, которые есть в модуле... Конечно можно и ручками придумать нечто подобное, но если велосипед изобрели до меня 

Для экспорта должен быть резон
Иногда гораздо читабельне вызывать функции по полному имени:
modules::printDatas::PrintHeader();
или для чего-то с зависимым содержанием создали класс, а потом вызывали через его указатель функции:
my $pd = printDatas::new();
$pd->PrintHeader();

А если Вам хочется заняться экспортом, то надо заметить, что экспортироваться могут не только функции, но и любые переменные, массивы, хеши.
а 
our @EXPORT;
push @EXPORT , '&PrintHeader';
... # куча push
проще описать как 
our @EXPORT = qw(PrintHeader PrintFooter PrintMainLinks);
не забывайте про списковый контекст, это часто очень удобный способ передачи данных

PS вообще плохой пример с названием modules, желательно что-то осмысленное. В лучше бы Вы подключили каталог modules в переменную просмотра путей для поиска модулей:
use lib qw(ваш_путь/modules ещё_один_путь_к_другой_группе_модулей);
use printDatas;
...
printDatas::PrintHeader();

PPS пустой блок END { } не имеет смысла, как и BEGIN стоящий в самом начале файла -- код в нем и так выполнится первым.
Главное чтоб Вы модули подключали через use, а не require, при первом способе компиляция выполняется при старте программы, при втором -- при обращении к ней.

Резон-то есть... Методы(процедуры) вызываются в основном скрипте, это все ж не просто классы экземпляры данных 




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




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

некромантирую свою старую тему. 

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

И даже для большего страха   переопределение функций не собственно-написных модулей или классов, а чего-нить из более стандартного.. Например какая-нить функция из того же DBI или CGI..

Ес-но, сама суть в том, чтобы организовать хак, при котором определенная функция переопределяется и начинает работать по иному алгоритму нежели стандартная 

P.S. Интересует именно переопределение, а не альтернативные реализации хака ))

SUPER псевдо-класс?






Это сообщение отредактировал(а) gcc - 15.9.2009, 12:10

делали.. для какого то мелкого модуля протокола STOMP..
Но если не используется OOP - это довольно шаткое решени.

Заменить процедуру в любом модуле легко
 

Однако, если эта процедуру кто ли-бо импортировал до момента подмены - у них останется старая. 
В этом весь трабл.


Поэтому если вы хотите такое провернуть, то нужно подменять процедуру в самом начале

Вот на этом моменте я тоже призадумался



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

gcc, не натыкается-ли твой способ на эти же грабли?? 

для множественного наследования есть давно: use NEXT; http://search.cpan.org/~flora/NEXT-0.64/lib/NEXT.pm

и много разных дополнений написанных на Си  use Class::C3; http://search.cpan.org/~blblack/Catalyst-P...st/Plugin/C3.pm
http://search.cpan.org/search?query=mro&mode=all

в каталисте в новой версии используется: 
Class::C3::Adopt::NEXT http://search.cpan.org/~flora/Class-C3-Ado...3/Adopt/NEXT.pm в отладке выводиться сообщение что нужно перейти на этот модуль

(проблем с переопределение в данном случае по-моиму не будет)




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





Это сообщение отредактировал(а) gcc - 15.9.2009, 19:12

Подменять чужие функции - вообще некрасиво.
Другое дело как это сделать менее убого..
Ну создайте отдельный модуль типа .. Startup, в котором весь этот кошмар и изложите.
А далее - либо первой строчкой своего скрипта его подгружайте, либо как startup.pl при старте mod_perl

sir_nuf_nuf, а NEXT тут разве не подходит? его автор сделал как раз для множественного наследования...

gcc, нет. он подходит только если наследование (т.е. ООП) вообще имеет место.
Мы же говорим про импорт обычных процедур. не методов объектов

Действительно, это важный момент, сохранять целостность семантики кода... Тот кто после меня посмотрит мой код должен понимать не только как, но и что в нем происходит, а когда налеплено где-то процедурное, где-то ООП - это тоже не красиво... 




Вариант..  может быть..