I define the attributes of the object just in the overloaded new method.Thus in one place. Setters and getters are handled centrally by the Parent. So that is not just saving typing it is keeping it compact and avoiding lines and lines of not really value added code.

So then all your attributes are public? And attributes which are defined by Parent::Child and Parent::Child::GrandChild are handled by code in the parent? Which means that code in Parent is directly accessing fields which don't belong to it. This is actually bad OO, and just because perl's (some would say broken) OO system lets you do it, does not mean you should do it.

My personal approach (and I am known to be a (sometimes) overly defensive programmer so take it with a grain of salt) is that I never create getters and setters until I actually see a need for one. And IMO it is bad OO design to have your superclass deal with anything which is specific to your sub-class. Your superclass should never need to have any knowledge or deal with attributes of your sub-classes in any way (regardless of how dynamic the code which makes it possible).

Let the machine do the boring work and you do the thinking.

My argument is that you shouldn't need to actually do the "boring" work unless your "thinking" tells you that it is nessecary. At which point you can implement whatever it is in a reasonable amount of time and not have to do it again.

Is that not the real way of being lazy?

No. The real way of being lazy is to do it right the first time (more work up front), so that you don't have to do it again when you realize it's wrong.

AUTOLOAD is an oft abused feature of perl's (akward) OO system. IMO it should be used with great caution, and only when nessecary. It's mis-use has tripped up many an perl programmer experienced and in-experienced alike. The simple fact that it negates any meaningful use of can is IMO enough to not use it.