I have developed a modest object-oriented interface to ARSPerl. The approach I took is somewhat different from the one offered by ARSPerl directly.
The approach is based on a two-tiered hierarchy: there is a generic superclass, and schema-specific subclasses that inherit from the superclass.
In practice, a script must be run for each desired schema which generates the schema-specific subclass. The subclass contains a few generic methods (such as a constructor) and a data-structure which describes the fields in the schema. Obviously: if the schema is modified, the data-structure must also be modified. (well, not exactly; if new fields are added to the schema, they simply won't be available in the interface until they are added to the data-structure.) Such an approach has its disadvantages. However, it means the interface can be very simple and straightforward. There is a method in the superclass for the purpose of comparing the schema to the data-structure which can be used to alert you should something in the schema change.
The perl AUTOLOAD() mechanism is used to automatically offer get/set methods for an object that correspond to the field names in the data-structure. Furthermore, the fields in the data-structure are marked as to whether they should be automatically retrieved by the standard query (getRecord()). When a get-method is called for a field whose value was not automatically retrieved, an additional query is transparently performed specifically to retrieve that value. (delayed initialization). Thus, you could mark diary or other large or unwieldy fields as not to be automatically retrieved and avoid the performance impact if you won't be referring to them very often.
Enumerated fields are handled transparently.
You can designate a field other than the request-ID in the data-structure as the default field to be used for queries. This field should contain unique values. If such a field has been designated, you can have the constructor perform a query for you. (see example below).
The "write()" method will transparently perform either an update or a create, depending on whether you performed a (successful) query before calling write();
My motivation was to keep the complication to a minimum at the level where the interface is actually used. Below are some simple examples.
some example code:
... and an example subclass.
The readme is here.
The source is ars-oo-xface-1.2.tgz