Harald Jörg

@leonerd started this with: > Lets for now entirely ignore the generated method names for :reader or :writer attributes This reminds me to a discussion in #44 ("`my $f` vs....

> Making my fields _directly_ available to a subclass feels like the same thing: a massive encapsulation violation and now I've tightly coupled the classes. That's why I like @leonerd's...

> But yes, that would require that a class has a (meta?) version attribute that‘s used to ensure this kind of safety. Depending on the use case, you might need...

In the same spirit I'd expect that a class method would also be able to use fields of its objects? That would make sense for functions which operate on a...

I have discovered that there's already a perltidy tool for Emacs, in the CPAN distribution [Emacs::PDE](https://metacpan.org/release/Emacs-PDE), and also apparently some forks of its perltidy.el. It doesn't support the ediff part...

Ah, ouch... thanks for the reminder. I could not find any version of perltidy integration into Emacs which has been kept up to date with current Emacsen and could easily...

So, I've now taken a first stab at this feature - for now, in a separate file perl-tidy-ediff.el. I am not so sure about how to distribute it "officially". I...

I apologize for the noise: I _thought_ that I had deleted my comment before anyone would notice. So you're answering my now-extinct question (about what makes "many non-ASCII mirrored bracketing...

Indeed, the distinction between "overridable" and "nonoverridable" keywords seems pretty arbitrary (why is `shift` shown as nonoverridable but `bless` isn't? Even if there _is_ some distinction deep in Perl's C...

Thanks for the pointer! This is an indication that Perl users don't care too much and supports your suggestion to just eradicate the distinction. The list changes between versions: for...