Оформите как крохотку пожалуйста

Зачем

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

Да не, там чувак серьёзный, его подрядили спецом. Он сначала написал спецификацию, теперь занят реализацией. Всё это пойдёт в ядро и по идее будет шустрее Moose. Но это не точно, это мои додумки.

Аргументы у методов через экспериментальные сигнатуры?

Сабж выглядит проще и удобнее. Однозначно нужно.

Вот только нужность ООП в Perl у меня всё равно вызывает сомнения.

Тогда уж и ссылку на реализацию надо было давать - Cor

Из того что сейчас в репе есть, ессно, ни о каком преимуществе в скорости перед Moose речи не идёт.

Завязка на экспериментальный postderef, помимо сигнатур, тоже не сильно понятна, но фиг с ним, это ж тестовая херня пока.

Как по мне, то из последнего полезного и суперкрутого, что видел на cpan, это Future::AsyncAwait

Вот только нужность ООП в Perl у меня всё равно вызывает сомнения.

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

Из последнего - работать с базой проще нередко.

Это да. Но проще переписать на Python. Это я тебе как любитель Perl и нелюбитель Python говорю.

Подозрительно знакомый синтаксис. То ли TypeScript пишет члены с :reader, :writer, то ли кто ещё, но где-то на глаза уже попадался.

postderef уже давно не экспериментальный.

экспериментальный postderef

postderef был экспериментальным последний раз в 5.22.

Вот все эти фигурные скобки в блоке кода хорошо смотрятся только без глубокой вложенки. Стоит создать вложенные конструкции – и в глазах зарябит от скобок.

Всё это пойдёт в ядро и по идее будет шустрее Moose. Но это не точно, это мои додумки.

А будет ли это шустрее Moo? И как оно в сравнении с, простите, ракой?

Сколько вариантов ООП в перле? Moose, Mouse, Moo, Mo, M? Сейчас будет ещё один. TIMTOWDI родил перл, он же его и добьёт.

Использую Mouse и очень доволен им. За скоростью не гонюсь. Если взлетит - пусть так и будет, важно чтобы принцип «не навреди» соблюдали.

Mo и M это шутейки, насколько я помню. Про Raku вообще мало знаю. Заказал в пиндостане 2 книжки по ентому языку. Одна потерялась по дороге, вторую ещё есть шанс получить. Приходите через год :P

Диалектов ООП в Perl'е гора. Лично мне всегда хватало базового. Было дело, игрался с Moo, и всё что о нём помню это:

perl -Moo -e'oo::moo'

Зачем это всё? Из коробки там достаточно ООП, не хуже питона. Черезжопно конечно, но это же перл, там всегда так. Лучше сразу привыкать к трудностям и лишениям. ЯП не для сладкоежек.

лет много назад мне один гражданин сверлил моск что в перле нет классов, совершенно игнорируя доводы, что они и не нужны, есть bless и этого достаточно
вобщем я ему родил это: http://paste.org.ru/?v6edyr
успокоился и довольный от меня отстал

postderef был экспериментальным последний раз в 5.22.

Ёбушки-воробушки. Давненько уже, однако.

Жаль наверное, когда потратил уйму времени на изучение технологии, а ее закопали. Можно переучиться, конечно, но это уже не то.

ООП в перле не нужно

Зачем это всё? Из коробки там достаточно ООП, не хуже питона.

Зачем вообще ЯП? Ассемблера достаточно.

Moose, Mouse, Moo, Mo, M? Сейчас будет ещё один. TIMTOWDI родил перл, он же его и добьёт.

во наркоманы если бы писали полезные утилиты или приложения вместо либ для ООП perl был бы более популярен

perl - это универсальный высокоуровневый кроссплатформенный ЯП - гораздо лучше bash

asm - не кроссплатформенный и не высокоуровневый

Ну вообще да. Но можно попробовать решить это на уровне цветовой схемы.

Mo и M это шутейки, насколько я помню.

M — шутка, Mo — вполне себе модуль.

Заказал в пиндостане 2 книжки по ентому языку. Одна потерялась по дороге, вторую ещё есть шанс получить.

Рутрекер в помощь.

Лично мне перловый зоопарк с десятками альтернативных реализаций базовых вещей (классов, исключений, и т. д.) как-то надоел. Вместо того, чтобы рисовать свою прикладуху, сидишь и копаешься в десятке реализаций try/catch…

Рака — not quite perl, зато в комплекте с батарейками.

Про Raku вообще мало знаю. Заказал в пиндостане 2 книжки по ентому языку

Не ты ли приносил новость про книжку Шитова. Она разве не в свободном доступе? Но я думаю лучше изучать раст. Это не хуже рака, даже название похожее.

зато в комплекте с батарейками.

Это речь об ООП и исключениях в поставке?

это шутка?

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

Прямо по классике. Мощные языки не выживают :(

ну чтото в этом духе
человек хотел классы - я ему сделал классы
само собой этот код дальше никуда не пошел

Рак, убивающий /perl/

Не только. Кроме классов и исключений там обширная стандартная библиотека. Я успел попользовать IO::Path, run для запуска процессов (с перехватом stdout и stderr, если надо).

В перле это всё тоже есть вроде бы , но во множестве альтернативных вариантов, из которых надо выбирать правильный.

Не выглядит удобнее Moose, да и зачем вся эта хрень? В перле есть ООП из коробки, неосиляторы bless не должны подпускаться к перлу.

Это слишком просто

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

ООП всё.

Лучше бы юзабельное ФП впилили :D

Ужас. Вместо подобных извращений, лучше бы стандартизировали базовую функциональность (композицию). В том же JS не важно, какой новый сахар вводят, он обязательно транспилируется/взаимодействует с кодом на ES3. А у нас даже async/await без костылей нет.

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