|Do you know where your variables are?|
I'd prefer to write that $self->Foo::_fiddle, even though it would be slower.
And that now means you're hardcoding the package name into the method call. Still, since you're staying within the package, this might not be a Bad Thing. I'll have to think about that.Don't understand what problem/assumptions [with a private method reaching into the object which ]you see as problematic here. Can you elaborate?
This can be a problem if you're subclassing. Let's say that a Tiger is a subclass of Animal and the creator of package Tiger; decides that a blessed array reference is the way to go. With proper encapsulation, this should be irrelevant. However, when you find out that package Animal; is a blessed hashref, that's probably how you will have to implement Tiger. Once you pick how to represent a particular class, you're likely stuck with it once you subclass.
Meanwhile, your tiger object must be uniquely identified, so you decide to create an MD5 digest for it:
Meanwhile, you've failed to realize that the Animal class has a private "_digest" key in the hashref to let it know if it's busy digesting food. That could be a real pain to debug, but you have to know your superclass's internals to avoid problems like this.
In reply to Re: Re: Re: Re: Often Overlooked OO Programming Guidelines