We are working around this issue ourselves. It is a pain. Using a singleton instance would really help. Keeping the set of static accessors methods that then use the singleton for implementation would both make overriding the peer behavior easier and preserve the existing contract.
russell > -----Original Message----- > From: Stephen Haberman [mailto:stephenh@;chase3000.com] > Sent: Tuesday, November 05, 2002 11:41 AM > To: 'Turbine Torque Developers List' > Subject: RE: reasoning behind so many static methods in BasePeer > > > > > What would be lost by having access to the peer classes by through > > GeneratedClass.getPeer() and having a single static instance of each > peer > > rather than having so much use of static methods. I see > that it would > > break existing code and I am not arguing that is not important to > avoid, > > but are there any technical reasons that I am missing? > > No, not that I know of. > > In the peers concept of Torque where the peer classes > represent tables, static works really well conceptually in > that it just doesn't make sense to have two instances of your > BOOKS table floating around in the VM. Static methods are a > hard and sure way of providing this. > > But you make good points; it would be better design to have > the Peers be objects with protected constructors or the like > and no static methods to enable all of the nifty polymorphism > stuff you're wanting to do. > > - Stephen > > > -- > To unsubscribe, e-mail: > <mailto:turbine-torque-dev-> [EMAIL PROTECTED]> > > For additional commands, > e-mail: <mailto:turbine-torque-dev-help@;jakarta.apache.org> > -- To unsubscribe, e-mail: <mailto:turbine-torque-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:turbine-torque-dev-help@;jakarta.apache.org>
