Довольно интересная разработка наших зарубежных товарищей — 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 - средство защиты авторских прав? Это что-то новенькое...

А для чего оно ещё надо?
Поступил модуль, ну так пользуй его как тебе вздумается.

И каким же образом можно защитить с помощью Private и protected авторские права? Нарушение авторских прав- это использование чужого кода с нарушением лицензии на него. В Perl это совершенно неуместно, и невозможно, по идеологии, собственно, самого Perl, какими бы закрытыми методы/переменные здесь ни были.

В Perl рекомендуют называть внутренние подпрограммы, начиная с символа подчёркивания "_". Это конечно до невозможности простой вариант, но отчасти довольно приемлимый, этот язык ведь призван облегчать жизнь программистам, в отличие от многих других) С переменными дела не очень, ну... у всех свои недостатки (© из к/ф "В джазе только девушки")

Внутренние переменные должны быть использованы для целостности данных, для этого и нужна инкапсуляция... Да и какое нам должно быть дело до приватных методов - разработчику (в некоторых случаях даже нам самим)) виднее, что в API лучше не вызывать напрямую. Shaqqie прав на счёт концепции программированя - переопределение и наследование не всех методов приводит к хорошим последсвиям.

Это сообщение отредактировал(а) everyone - 8.9.2007, 11:17

Про какие авторские права вы говорите? По вашему мнению я могу объявить класс с private членами и мой код будет защищён авторским правом?
Класс для пользователя выступает как черный ящик и ему совершенно необязательно знать что у него внутри, вот что бы не было никаких недоразумений и вмешательства во внутреннюю работу, всё что нужно для успешной работы я дам к нему доступ, то к чему не нужно я скрою(объявлю как private  или protected)

авторские права должны защищаться законом, и только им. Где-то этот момент и правда работает.
что касается private и protected - они нужны! для проектирования. В языке с ООП должны быть приватные функции, если он претендует на универсальность. А пользоваться им или нет должен решать тот, кто применяет его. Часто ситуация решает это за разработчика - необходимость хорошего, читаемого кода.

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

чем сложнее украсть функцию private, чем public... мне сложно сообразить. Если это кому-то понадобиться, то ничего не поделаешь)

интересно бь узнать что это за программа была с таким ООП, что показал, уважаемый  tishaishii

а где еще такие примеры найти которых нету в книгах ?   

кстате, в  Catalyste такого тоже не ту вроде бы встроенного...

Это сообщение отредактировал(а) gcc - 23.1.2009, 23:40

Ну вот ты и поспешил....
А меня сегодня через PM по поводу этой темы ProFTP разбудил.
Так я пример твой посмотрел-посмотрел... И думаю, ну не стоит так. Ну явно же в твоём коде уловка есть (это я по инерции мышления).
У класса Father не обозначено собственного метода m1, а есть только наследованный из Class. Ну не указан в описании модуля и всё (чтоб других проверить и дело запустать).

А противорячия принципу наследования "Кто первый - тот и прав", я пока не нашёл.
Из твоего примера, в пакете main я вызываю Child->new->m1 и получаю вызов изначального метода Class::m1, за неимением другого в классе Father. А вызывается именно Class::m1, т.к. Father в списке родителей был указан первым.

ISA(Child=>Father, Mother(m1), Neighbour(m1));
ISA(Father=>Class(m1));
Child::SUPER::SUPER::m1;

Не прошёл твой номер.  

Это сообщение отредактировал(а) tishaishii - 27.1.2009, 18:42

1) может кто-то объяснить про tie в OOP? не понял я в этом топике примеры... смысл? как понять архитектуру этого интерфейса которые делается на tie? 

я в perl почти все понял но кроме tie....

2) а как сделать Child::SUPER::SUPER::SUPER::m1 ?

tie связывает структуру Perl с какими-то данными.

С помощью tie можно связать структуру с классом и таким образом изменнить функциональность структуры.

мне это видится так

Добавлено через 2 минуты и 23 секунды
Здесь можно найти ответы на многие вопросы, касающиеся tie и OOP.

этот пример я читал,  я "связал", а что дальше делать? где приемущество?

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