Стоп, стоп, ребята! Perl - язык мультипарадигменный. В том числе есть поддержка и ООП. При чём, здесь, как и в прочих аспектах, Perl придерживается TIMTOWTDI. Из коробки есть реализация через благословлённые ссылки. Есть кто, несогласный, что это ООП?
Помимо этого, «в Perl 5 было реализовано всё, в том числе возможность реализовать всё». Например, с помощью модуля Moose подключается одна из мощнейших реализаций ООП. Есть и другие реализации, вплоть до разграничения доступа к методам/полям исходя из пользователя, времени суток.
Если нужна реализация ООП, подобная Java, C++, C#, PHP - милости просим: есть модуль Pony::Object, добавляющих пару ложек синтаксического сахара для привычного ООП.
В общем, заходи на http://metacpan.org и выбирай. Установка модулей производится «sudo cpan Имя::Модуля» .
В том числе и ООП. В первую очередь он процедурный (таким родился). Затем в него добавили ссылки, и потом уже благословленные ссылки (объекты) прибили гвоздями. Как это работает посмотрите тут: perldesignpatterns.com
Дефолтная концепция слабовата (нет управления наследованием, доступ к полям, автогенерация акцессоров/мутаторов, интерфейсов, трейтов и прочих наработок), зато очень гибкая и простая. Для гурманов есть модули усиливающие концепцию: Moose, Moo, Pony::Object ...
Сам использую конструкцию из самописного базового класса + кодогенератор методов доступа к членам класса (Class::Accessor::Fast).
Пример с вакансиями, где требуют знание ООП-языков (плюсы, Java). Все остальные языки не считают ООП-языками. Если на собеседовании вы скажете что perl/php/lisp/erlang тоже какбэ такие, то вас посчитают дурачком.
Еще одна таксономия: статично-классовый подход против прототипного. Единственным верным и аутентичным все еще (таков стереотип, часто встречается) считается первый.
За не умение использовать cpan в $HOME надо давать по рукам! :-\
Есть кто, несогласный, что это ООП?
Если следовать Гради Бучу, то в перле ООП напрочь разрушен тем, что позволяет легко менять содержимое объектов вне основного класса: $obj->{value} = «abc». Также применение ООП в перле приводит к проблемам производительности, т.к. изначально не планировалось вводить никакого ООП в язык. Поэтому, можно говорить только о том, что перл позволяет писать в ООП-стиле, но это не является доказательством того, что в перле имеется 100% поддержка ООП. После изучения Java, где ООП является основой языка, перловый ООП просто курам на смех. ИМХО.
Это не понты, а правильное использование инструмента. В зависимости от настроек, а также целей и возможностей, то коль часто тебе захочется редактировать чужие модули через sudo vim ? :)
Классы = 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).
Тут пару год назад сравнивал скорость инициализации Pony::Object на Perl 5.10 и 5.16 - выигрыш в 5 раз.
И ? Moose уже 3 раза форкулся, что не сделало его быстрее ветра :) Я вот смотрю код Pony::Object и вижу только PP. С учетом того, что на PP трудно достичь высот, то и говорить о какой-то мифической производительности смысла нет. Я имел ввиду, что в perl 5 за последние н-лет ООП особо никто не оптимизировал.
Нынешнее понимание ООП вообще не об объектах и сообщениях. Так к чему сдерживать себя рамками? :-D
Давай начистоту. Чтобы ты выбрал для изучения ООП: Perl или Java/C++ ? Если посмотреть на англоязычную литературу, то ты не найдешь ни одного учебника о том «как программировать» на основе Perl. Зато есть масса курсов, литературы, направленной на фундаментальное изучения программирования на других языках: C, C++, Java (я тоже не фанат ЯП без указателей, но всеже) и т.д.
А грузовик — это грузовик. Ты же понимаешь, что это не является определением. И, как тут уже говорили, чуть ли не каждый первый по-своему ООп определяет (а некоторые даже «исповедуют»)
Ну почему же, если _стремиться_ к конструктивной дискуссии, то можно отталкиваться от «язык, который облегчает ооп-стиль, имеет набор языковых средств» - выделить основые моменты, формализовать «средства».
Для ООП существует несколько достаточно противоречивых определений в различных источниках. Лично я встречал варианты от «объект содержит свойства, методы и события» до вывода понятия объекта на основе тории категорий.
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.