MooseStyle: Self-made inline vs cpan-based inline
I have read the "Add-Moose-style-attribute-accessors-to-your-Perl-classes" article from David Farrell.
I understand his issue with "sans dependencies" but was uncomfortable with
his solution. To write this code-snippet everytime (or copy&past)
and maintain every file feels wrong.
I rememberd of Mo and Mo:Inline.
What turned out to be better than in my memory.
What are your opinions?
Mo::Inline is a cool idea, but the extreme golfing used by Mo for very little reason makes it something I'm no longer comfortable using in production code.
Hopefully David Golden will achieve his ambition for Class::Tiny to be added to core, then all such silliness can end.
What Mo does isn't really golfing in the way it's typically known, but mostly minimization in the same style as many JS minifiers do it. Unless you have specific complaints, you have no reason to worry about it.
Also, it is done for the very specific reason that this way it can be dropped into software with copy&paste without even changing the line numbers.
An inlining script could easily fiddle the line numbers.
Hey Matthias,
Thanks for considering the article even worth discussing :) I'll check out Mo::Inline.
One thing I wanted to clarify: generally I would advocate using Moo/Moose over vanilla Perl OO, but there seems to be a lot of interest in vanilla Perl OO articles (our most popular article is Old School OO Perl, hence the article.
With Moo/Moose you could achieve something similar with:
for (qw/x y/) { has $_ => ( is => 'rw') }
Either way it's a limiting pattern - especially for argument checking which would be a PITA to implement this way.
Thanks,
David
I would has discussed it there, but your blog has no comment system.
It's just bugging me that something so simple has so many hackish homebrew solutions.
I know TMTOWTDI but sometimes I wish me more common solutions. And Mo::Inline had looked like a good compromise. At least for me.
Or in Moose/Moo:
nice!
An upgrade to Mo::Inline appears to be behind this issue for YAML:
https://rt.cpan.org/Ticket/Display.html?id=90817
and I think a similar issue was behind this:
https://rt.cpan.org/Ticket/Display.html?id=76664
It's not the most pleasant code to be debugging either.
It's an interesting idea, but I'm treating it as a warning sign in code in future, particularly anything that so many other modules depend on.
Is your issue about Mo or about non-core dependencies?
At least Mo::Inline can update all your scripts with one command.
> Is your issue about Mo or about non-core dependencies?
Neither - it's about modules which use Mo::Inline. Mo itself seems fine, if a module uses it and works, that's great. Non-core dependencies... the more the merrier. I have no objections to a module depending on Mo itself. My specific complaint (as Mithaldu was asking) is that debugging something which has been through the Mo::Inline process is a headache I'd rather avoid.
Granted, YAML is perhaps an extreme case, several things depend on it so breakage is very visible, and it's mildly disheartening to open the RT queue and see that there's >100 open tickets to check.
Also, please note that ingy has already released a new version of YAML which so far seems to resolve the problem -
At least Mo::Inline can update all your scripts with one command.
That's a nice feature.
My main issue is that these aren't my scripts/modules: if something breaks in a dependency it's usually worth taking a look at the source to see if it's an easy fix.
In this case... apparently there was a bug somewhere in here:
at which point I close the editor and look for other options...