It is important to be aware that I am neither steeped in OO theory nor have I amassed a great deal of experience from which I can speak with authority. Having limited exposure to what's established means I might have fresh perspective, but I might also just fall right into a pit. Only an innocent child could get away with such blasphemy. God bless them all. Amen..

Let's consider a Circle object. It's got properties like Area, Radius, and Circumference. (Interestingly, they're all different views of the same fundamental property.) The usual approach might be to have methods setArea, getArea, setRadius, etc. Notice that those names look like classical procedural programming names: what they operate on is part of their name, rather than being the object that owns the method.

An OO approach would be to have the properties be "sub-objects", and the accessors would be called like $myCircle->Area->set(5). You can see that Area could be either the sub-object itself (see tie for Perlish, encapsulated objects), or a function returning the sub-object, depending on your philosophy. Once I started thinking of properties as sub-objects, I found myself preferring method-returning-object over a distinct syntax for returning properties.

Now, since we've got three sub-objects with the same interface (set of methods), it seems reasonable to have a virtual class that defines that interface: a setter-getter scalar class. As it happens, such a virtual class is already defined for us by Perl. It's the scalar class we can tie to. However, the more I thought about it, the less useful it seemed to actually provide a tie-able interface to properties. It was just an interesting side-note.

Update: Well, I had included some example code, but a fat-fingered update ended up deleting it. Probably just as well; it distracted people from the point more than it helped them understand it. The point is: there is a more properly OO approach, but it involves some programming and performance overhead.

holli offers a very nice example below.