Maybe so. for some reason I thought Python made it hard to modify a class after declaration. I might be thinking of PHP, or maybe I tested something on a C-ba

Maybe so. for some reason I thought Python made it hard to modify a class after declaration. I might be thinking of PHP, or maybe I tested something on a C-backed object without realizing. For what it's worth, Perl lets you freely mix C methods with pure-perl methods in the same object. I also don't think Python has an equivalent for Inline::C https://metacpan.org/pod/Inline https://metacpan.org/pod/Inline Getting back to the Moo topic though, you seem to hate the idea of reading user-module documentation to use an object system, but I see that as one of Perl's strengths. Perl's native object system is nothing more than data elements (usually hashrefs, aka dicts) "blessed" with a method table, and the method tables are nothing more than a dict of methods and variables. And you can use user-written modules to generate those packages, and create whatever syntax you like with the user-written modules without depending on core perl to add features. Reading the @cached_property Stackoverflow pages, it sounds like the way to implement this has changed several times over the past decade of Python versions. Moo works as-is on all perls since 5.8, released in 2002. The ability to take some basic mechanics and build on top of that is what I like. There are dozens of object systems available in Perl because people were free to experiment. Moose was the first one that gained a lot of traction because it solved a lot of common needs. Moo gained a lot of traction for solving most of the same problems while being much lighter weight. I don't think it's any worse to read the manual for Moo than to read the manual for the decorators that Python provides.