Re^2: Perl OO and accessors

Within the class package, accessors and mutators are heavily used for typo avoidance -- or rather, compile-time typo checking.

Considering that Perl does look up of methods at run-time, what checking is done at compile-time?

(And yes, inside-out objects address some of that, with yet other tradeoffs.)

Nowadays, I usually use inside-out objects, and that means I don't write accessor all that often. I don't use objects if I want C-type structs, hashes will do fine in that case. For other cases I only provide methods to the outside world for those cases where the outside world might want to inspect (or set) some state of the object. This may be an accessor, but the outside world neither knows, nor has the need to know.

I never use accessors to let a class get at its own data. IMO, there's no point in adding the overhead of calling a method to get a value from a hash, and I prefer the compile-time errors I get from making typos when accessing the data instead of the run-time errors when typoing a method name.

For me, the existance of an accessor means that I intended the outside world to set, or look at a state. And that I hence should be careful when redoing the internals.

Perl --((8:>*

Comment on Re^2: Perl OO and accessors

Replies are listed 'Best First'.
Re^3: Perl OO and accessors by dragonchild (Archbishop) on Nov 29, 2005 at 12:54 UTC
I never use accessors to let a class get at its own data. That's an interesting statement. I actually always use accesors when dealing with attributes to allow for subclasses to override how they wish to deal with an attribute. But, I tend to work either with datastructure-type classes like Tree where the algorithms of the class need to be separated from the datastorage of the class or with templating engines like Excel::Template where a given node doesn't know if it actually has the attribute or not. (Its parent might have the attribute, so it has to ask a separate context object where the attribute actually has a value.) My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^4: Perl OO and accessors by xdg (Monsignor) on Nov 29, 2005 at 13:26 UTC
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) -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply]
Re^5: Perl OO and accessors by chromatic (Archbishop) on Nov 29, 2005 at 19:27 UTC
Your use of the phrase "automatically defaults" regarding Class::Std must have some meaning with which I was previously unaware! :)	[reply]
Re^5: Perl OO and accessors by herveus (Prior) on Nov 29, 2005 at 20:21 UTC
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	[reply]
Re^4: Perl OO and accessors by Perl Mouse (Chaplain) on Nov 29, 2005 at 13:10 UTC
I actually always use accesors when dealing with attributes to allow for subclasses to override how they wish to deal with an attribute. One of the reasons I use objects is because of encapsulation. Nothing, but the class itself, is allowed to have behaviour that's depending on the class' implementation. And that includes masking accessors. A subclass is not even allowed to know what is an accessor and what isn't. `Perl --((8:>*`	[reply]