Perl и ООП

Насколько я помню,нет.Но есть различные «финты конями»,с помощью которых достигаются возможности ООП

Учи лисп. Он ООП.

Это наоборо хорошо, ибо ООП не понравился. Но сейчас все работодатели за ООП.

Это не сейчас,это уже давно

Да. Но не так, как это принято в C

См. «Программирование на Perl», Ларри Уолл, Том Кристиансен, Джон Орвант, глава 12 «Объекты»

Ты только начал изучать программирование и для начала взял пёрл?

Если да, то — правильный выбор. Но, нет. Он не ООП.

Что-бы тебе не рассказывали — не верь. Пёрл не ООП.

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

// и, конечно же, — ООП ненужен. (совсем, вообще)

Стоп, стоп, ребята! Perl - язык мультипарадигменный. В том числе есть поддержка и ООП. При чём, здесь, как и в прочих аспектах, Perl придерживается TIMTOWTDI. Из коробки есть реализация через благословлённые ссылки. Есть кто, несогласный, что это ООП?

Помимо этого, «в Perl 5 было реализовано всё, в том числе возможность реализовать всё». Например, с помощью модуля Moose подключается одна из мощнейших реализаций ООП. Есть и другие реализации, вплоть до разграничения доступа к методам/полям исходя из пользователя, времени суток.

Если нужна реализация ООП, подобная Java, C++, C#, PHP - милости просим: есть модуль Pony::Object, добавляющих пару ложек синтаксического сахара для привычного ООП.

В общем, заходи на http://metacpan.org и выбирай. Установка модулей производится «sudo cpan Имя::Модуля» .

«sudo cpan Имя::Модуля»

Ну вот. Об этом я и говорил.

Красивый, прекрасный, _процедурный_ язык, многие хотят превратить во всякое непотребство.

И всё это только потому-что он настолько гибок, что может (почти) всё что угодно.

Из-за всех вас, и всех ваших стрёмных желаний, — мне становиться жалко пёрл.

// Процедуры рулят!

Красивый, прекрасный, _процедурный_ язык, многие хотят превратить во всякое непотребство.

ООП мне представлялось развитием процедурного подхода. Вы так не считаете?

И, да, слава Кларку, в ядро не пихают Moose, mop и прочее. Так что Вам ничего не угрожает :)

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

Красивый, прекрасный, _процедурный_ язык,

с эпитетом явно погорячился

Но сейчас все работодатели за ООП.

Вылезай из криокамеры. Это уже давно не в моде.

Perl такой же ООП, как и ANSI C. Т.е. хочешь ООП? Будет тебе ООП!

На самом деле многие библиотеки перла в ООП стиле написаны.

http://blob.perl.org/books/beginning-perl/3145_Chap11.pdf

Думаю, в слово «ООП» ты вкладываешь более другой смысл, чем ТС.

ООП мне представлялось развитием процедурного подхода. Вы так не считаете?

Не считаю :) . Развитие не всегда идёт так как нужно. Один «влиятельный» голос «за_новое» — перекрывает тысячи голосов «против_нового».

Процедурный подход для девяти из десяти программ подходит намного лучше чем любой другой.

Причём во всём, будь то: проектирование, разработка, обслуживание, доработка.

Вообще я хотел донести автору то, что, выбранный им язык — процедурный. И это, по моему мнению, очень правильно.

// Moose, mop и прочее ← я ничего про это не знаю / не слышал / не встречал / не использовал.

с эпитетом явно погорячился

Ни разу нет. Perl — красивый, прекрасный, и именно процедурный язык.

// Moose, mop и прочее ← я ничего про это не знаю / не слышал / не встречал / не использовал.

https://metacpan.org/module/Moose https://github.com/stevan/p5-mop-redux

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

Мой же посыл - Perl неограничен (даже с точки зрения грамматик).

Но есть один вопрос - он ООП?

В том числе и ООП. В первую очередь он процедурный (таким родился). Затем в него добавили ссылки, и потом уже благословленные ссылки (объекты) прибили гвоздями. Как это работает посмотрите тут: perldesignpatterns.com

Дефолтная концепция слабовата (нет управления наследованием, доступ к полям, автогенерация акцессоров/мутаторов, интерфейсов, трейтов и прочих наработок), зато очень гибкая и простая. Для гурманов есть модули усиливающие концепцию: Moose, Moo, Pony::Object ...

Сам использую конструкцию из самописного базового класса + кодогенератор методов доступа к членам класса (Class::Accessor::Fast).

ООП --- Объектно-Ориентированное Программирование. Какой ещё смысл тут может быть?

Какой ещё смысл тут может быть?

Извращенных смыслов очень много придумали.

Пример с вакансиями, где требуют знание ООП-языков (плюсы, Java). Все остальные языки не считают ООП-языками. Если на собеседовании вы скажете что perl/php/lisp/erlang тоже какбэ такие, то вас посчитают дурачком.

Еще одна таксономия: статично-классовый подход против прототипного. Единственным верным и аутентичным все еще (таков стереотип, часто встречается) считается первый.

1. Ну зачем же здесь, на лоре подстраиваться под идиотов. Мы же не на собеседовании.

2. Вопрос нужно было тогда задавать в стиле: похожа ли объектная система(-мы) перла на объектные системы жабы и с++.

sudo cpan Имя::Модуля

За не умение использовать cpan в $HOME надо давать по рукам! :-\

Есть кто, несогласный, что это ООП?

Если следовать Гради Бучу, то в перле ООП напрочь разрушен тем, что позволяет легко менять содержимое объектов вне основного класса: $obj->{value} = «abc». Также применение ООП в перле приводит к проблемам производительности, т.к. изначально не планировалось вводить никакого ООП в язык. Поэтому, можно говорить только о том, что перл позволяет писать в ООП-стиле, но это не является доказательством того, что в перле имеется 100% поддержка ООП. После изучения Java, где ООП является основой языка, перловый ООП просто курам на смех. ИМХО.

где ООП является основой языка, перловый ООП просто курам на смех. ИМХО.

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

За не умение использовать cpan в $HOME надо давать по рукам! :-\

Знаем и про local и про carton с perlbrew. Но если девелопишь один на машине, к чему понты?

Если следовать Гради Бучу, то в перле ООП напрочь разрушен тем бла-бла-бла

Абтракции создаются? Инкапсуляция есть? Наследование? Полиморфизм?

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

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

Но если девелопишь один на машине, к чему понты?

Это не понты, а правильное использование инструмента. В зависимости от настроек, а также целей и возможностей, то коль часто тебе захочется редактировать чужие модули через sudo vim ? :)

Абтракции создаются? Инкапсуляция есть? Наследование? Полиморфизм?

Да, но речь не об этом.

Как и везде.

Не везде. В той же java были сделаны многие оптимизации для быстродействия, чего не скажешь про перл :)

Мои поздравления.

Он ООП.

Классы = package, методы - sub, экземпляр объекта это по сути хеш, который ты создаешь сам в инициализирующем методе (принято в new, но не обязательно).

package Object;

use strict;
use warnings;

sub new {
    return bless {};
}

1; # обязательно!

Вот это минимум для класса.

Остальное читай в кэмел-бук и спрашивай. Да, про cpan.org не забывай.

Еще очень порекомендую посмотреть модули Moo и Moose. Они дадут тебе значительный прогресс в написании кода в ООП-стиле.

А так - молодец, перл - хороший язык, пусть его все и ругают.

коль часто тебе захочется редактировать чужие модули через sudo vim ? :)

Ок, local::lib в этом плане приятнее, но если деплоишь под юзером по соседству - нужно помнить и о нём.

Да, но речь не об этом.

Нынешнее понимание ООП вообще не об объектах и сообщениях. Так к чему сдерживать себя рамками? :-D

В той же java были сделаны многие оптимизации для быстродействия, чего не скажешь про перл :)

Тут пару год назад сравнивал скорость инициализации Pony::Object на Perl 5.10 и 5.16 - выигрыш в 5 раз. Да и в остальных моментах Кларк даёт жару (на примере cpanm https://travis-ci.org/miyagawa/cpanminus).

Абтракции создаются? Инкапсуляция есть? Наследование? Полиморфизм?

Это есть в хаскеле, что дальше?

Я вот пришел к мысли - что опп (мне сойдет такое понимание: http://wcook.blogspot.de/2012/07/proposal-for-simplified-modern.html) это _средство_ реализиции перечисленных абстракции, соотвественно - не единственное.

А вы какого определение ооп исповедуете?

Тут пару год назад сравнивал скорость инициализации Pony::Object на Perl 5.10 и 5.16 - выигрыш в 5 раз.

И ? Moose уже 3 раза форкулся, что не сделало его быстрее ветра :) Я вот смотрю код Pony::Object и вижу только PP. С учетом того, что на PP трудно достичь высот, то и говорить о какой-то мифической производительности смысла нет. Я имел ввиду, что в perl 5 за последние н-лет ООП особо никто не оптимизировал.

Нынешнее понимание ООП вообще не об объектах и сообщениях. Так к чему сдерживать себя рамками? :-D

Давай начистоту. Чтобы ты выбрал для изучения ООП: Perl или Java/C++ ? Если посмотреть на англоязычную литературу, то ты не найдешь ни одного учебника о том «как программировать» на основе Perl. Зато есть масса курсов, литературы, направленной на фундаментальное изучения программирования на других языках: C, C++, Java (я тоже не фанат ЯП без указателей, но всеже) и т.д.

А грузовик — это грузовик. Ты же понимаешь, что это не является определением. И, как тут уже говорили, чуть ли не каждый первый по-своему ООп определяет (а некоторые даже «исповедуют»)

ни одного учебника о том «как программировать» на основе Perl.

знаю два:

- Mastering Algorithms with Perl

- Higher-Order Perl: Transforming Programs with Programs

А грузовик — это грузовик.

Открой ПДД. Там всё чётко.

Ты же понимаешь, что это не является определением.

Да. Это является расшифровкой аббревиатуры.

> он ООП?

ооп в голове, а не в яп.

ооп в голове, а не в яп.

Ну почему же, если _стремиться_ к конструктивной дискуссии, то можно отталкиваться от «язык, который облегчает ооп-стиль, имеет набор языковых средств» - выделить основые моменты, формализовать «средства».

«Грузовик» — не аббревиатура.

Для ООП существует несколько достаточно противоречивых определений в различных источниках. Лично я встречал варианты от «объект содержит свойства, методы и события» до вывода понятия объекта на основе тории категорий.

Higher-Order Perl: Transforming Programs with Programs

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

Mastering Algorithms with Perl

Не читал, но быстрый посмотр говорит о том, что эта книга может претендовать на учебник. Что ж, был не прав.

Давай начистоту. Чтобы ты выбрал для изучения ООП: Perl или Java/C++ ?

Хм, выбор не богат, посмотрим: Java - полностью ОО, как следствие, человека сразу окунают в это со словами: «Была у вас точка входа в main, теперь она - статический метод 'main' класса HelloWorld» - почему именно этого класса, что такое «статический метод»...

С++ - вход чуть по-легче, но когда начинается protected-наследование, дружба классов, виртуальные методы - опять всё скатывается в непонимание при отсутствии хорошего преподавателя.

Perl - тут ООП выходит логично из концепции разыменования. После tie, благословлённые ссылки логичны и просты. Проблема здесь в том, что не все дойдут до этого - Perl специфичен...

В своё время мой любимый мат-мех выбрал за меня: в рамках курса ООП рассматривались реализации именно Java и C++ (видимо, посчитали их более «каноничными»). Параллельно шёл Perl. Так что в итоге различные реализации дополнили друг друга (в моём восприятии), а не противоречили.

Я вот смотрю код Pony::Object и вижу только PP

А что тут такого? Pure Perl прекрасен! Да и метапрограммирование в Perl удобно. Возможно, после 1.0 запарюсь за XS.

Я имел ввиду, что в perl 5 за последние н-лет ООП особо никто не оптимизировал.

А что оптимизировать? Moose? - так не всем он нравится, к тому же, сам виноват, что так растолстел :) Mouse, Moo, Mo, M? Кому-то нравятся Class::*. Так вот и выходит, что кого-то конкретного оптимизировать нет смысла.

Сейчас вот Стивен Литтл пилит очередную реализацию mop - людям (kraih, miyagawa, прочие перлисты, на которых подписан) нравится. Может, в 7ку именно его и впилят. Хотя, мне бы не хотелось.

Сейчас вот Стивен Литтл пилит очередную реализацию mop - людям (kraih, miyagawa, прочие перлисты, на которых подписан) нравится. Может, в 7ку именно его и впилят. Хотя, мне бы не хотелось.

Те ребята пишут just for fun. Если посмотреть внимательно их код, то окажется, что он сделан на 4+ из 5, под себя и не учитывает интересы других. Так что пусть пилят свой перл сколько хотят. А пока все их новшества сливают в производительности и никто не замечает, что все что они хотят (кроме синтаксиса) уже сделано в той же java.

Для ООП существует несколько достаточно противоречивых определений => если ты имеешь в виду какое-то конкретное, следует уточнять это явно.

прочёл сначала «Pеrl и РПЦ». Задумался.

я с просони прочел как «Perl и ОПГ».

А я вообще не прочел, просто пиши в тред.