Stephane Bailliez <[EMAIL PROTECTED]> writes: > Hello, > > I would appreciate some enlightments about the rational of having static > methods on peers in Torque. > > With time, I think that a better approach would be to have singleton on > these instances to benefit from an interface and method overriding rather > than method hiding. We should be able to get the singleton peer from the > object via a static getPeer method or such. > > The main problem right now, is that we cannot design a generic set of > operation on Peers. (or at least I'm unable to do so) Say I have A and B and > each of them has a customized peer APeer, BPeer which method doSelect hide > the base one because I want to add some precondition/postcondition. > > Now say I want to perform a batch selection of A and B via a generic select > operation, I would use instances of APeer and BPeer in an operation that > takes a BasePeer[] argument. > Now due to method hiding I'm in trouble to perform the appropriate > doSelect() on APeer and BPeer. How to call the right static method ? yay ! > Using reflection is the only option AFAIK. > > Of course at some points it is problematic for retrieveByPK signatures since > Java as of now does not allow covariant return type (JDK 1.5 I'm afraid). So > these methods must return an Object. > > Any stupid things in what I'm saying ? :o)
Stephane, this has been discussed to death (see the archives). Everyone is in favor of moving Torque away from statics. Dan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
