I actually always use accesors when dealing with attributes to allow for subclasses to override how they wish to deal with an attribute.

But that brings us back the the whole public/private/protected/friend issue of encapsulation of data in Perl objects (or lack thereof). If what Perl Mouse describes as a class's "own data" is private data specific to the implementation, then it's perfectly acceptable not to use an accessor -- though that may limit the ability of a subclass. (Not all classes need to be subclassable.) If subclassing is desireable, then it may make sense to implement "protected" accessor/mutators that can only be called by subclasses -- at least for data which pertain to general properties of the object which would be relevant to subclasses.

One benefit of inside-out objects for OO purists is that such subclassability must be made explicit. By default (under the most commonly-seen implementations, anyway), all properties are lexicals and thus private and can be used directly. Accessors/mutator need only be written when it makes sense for the interface, whether that is fully public or only for subclasses.

Any inside-out object generating module that automatically defaults to creating accessors/mutators for all properties defeats this benefit of inside-out objects towards encouraging "good" design. <cough>Class::Std</cough> (whoops -- misread the docs)

Your use of the phrase "automatically defaults" regarding Class::Std must have some meaning with which I was previously unaware! :)

Howdy!

Ummm...to expand on chromatic's remark, Class::Std *does* provide a way to have it generate accessors and mutators on the fly, but neither is done by default.

I'm glad you put quotes around "good" there. Creating accessors and/or mutators is not, per se, good or bad. It may be beneficial to start out with accessors and mutators in place to limit the number of places where the attributes are directly messed with. Doing so gives you the ability to change the storage mechanism without breaking your API, even within the package itself.

I also use "attribute" to include anything that looks like an attribute even if it isn't directly stored as a value (such as radius vs area for the famous circle). It's a Good Thing for the API to blur the distinction between attribute-like things that are computed versus those that are directly stored, as the user of that class has no Need To Know how the data is stored within the object.

yours,
Michael

I actually always use accesors when dealing with attributes to allow for subclasses to override how they wish to deal with an attribute.