So, where to begin on this?
The ability to handle and manage getters and setters is rife with trouble, at the moment.
- Having an addXXX() method does not remove the requirement of a setXXX() method
- In theory get/set is anathema to the add/iterate model; in addition, the current model, which allows for 'arbitrary' mix-and-match doesn't actually work out.
- addXXX() is all well and good, but when it comes to revert the object from cache, we're dependent on setXXX()'s presence.
One of two things is going to need to happen in order for this to be normalised.
1) We dump 'arbitrary' get/set/add combinations, and move to one of two handler pairs: It's either a getCollection/setCollection handler, which handles getting and setting of the complete collection, or an add/iterate handler which supports adding, iterating, and calling remove() on the iterator.
2) We start allowing the calling of private or protected methods, so that API which is critical to not make public can be created on the objects, but refused as public API.
Option 1) has the benefit of cleaning up a great deal of logic, in theory, across the board - method discovery becomes method-pair discovery, and it provides a nice place to push code for handling the brains of getter/setter handling.
Option 2) has the benefit, if widely accepted, of allowing people to designate non-public API as accessible by Castor, to allow for developers to lock down their API for other developers on objects without requiring expensive copy operations on these objects.
Status quo is, IMO, not an option.