On 17.07.12 10:41, Thomas Fox wrote: > Probably we can add the MapBuilder's methods as protected methods to the > Peer class, without even changing the Peer public interface. On the first > look, this looks like a good idea, and the public API stays the same for > the Peers, so it's better for the user (less generated classes) (and in my > opinion, the additional two or three protected methods in the generated > peers do not make the class too complicated.
+1 > Thinking again about dissolving the RecordMapper into the PeerImpl class, > this would add one public method (and a bunch of protected methods, one for > each column) to the PeerImpl class. Which is again probably acceptable for > the user, but adds still more complexity to the peers. +0 > Dissolving the RecordMapper into the PeerImpl class is also problematic > because the Data Object classes can have protected getters and setters for > some fields (whenever the user sets protected="true" on a column), so the > RecordMapper must be in the same package as the data object class. We also > cannot make it protected because the peer class can be in another package > (at the moment). Let me dig around a bit. Maybe some of the dependency injection patterns can help. > Regarding the Peer and PeerImpl classes, of course we can go back to just > static methods, with all their problems (e.g. cannot be exchanged on > runtime, e.g. for unit testing). No, please don't even consider this. I'd rather strive to reduce statics in Torque much as possible. > We could also look at a compile-time switch to generate either just static > methods or impl classes, (but we have a lot of switches already, which does > not make testing easier). Rather not. What about a single static method getPeer() that returns the PeerImpl in the data objects? IIRC, its already there only not static. > What are your opinions ? I'm undecided. I'll see how far I can get with a generified BasePeerImpl. Maybe the starting point is then easier to see. Bye, Thomas. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
