Personally I'd just have the singleton and ditch the static wrapper completely, however I recognise that having the wrapper would keep is closer to what exists already, so I'm not overly concerned. A method to get the singleton would make sense to match the set and would allow you to get an extended version of the back-end should that be available.
Thanks Joe On 30/11/06, Thomas Fischer <[EMAIL PROTECTED]> wrote:
Ups, I knew I forgot something on the list. This was in my mind but did not make it into the email. As you wrote, the problem of static methods is that you cannot override its behaviour. The beauty of static methods is that invocation is very simple. The idea would be to have a static Wrapper class, which holds a singleton of the class with the implementation, and which passes all its static calls to the implementation class. There would be a setter of the singleton in the static class, so the backing class would be exchangeable. So one can use the static class if simple invocation is wanted, and the implementation class if maximum flexibility is needed. Thomas [EMAIL PROTECTED] schrieb am 30.11.2006 11:58:25: > Is there any chance we can make the Peer classes non-static? > Currently it's hard/impossible to override/extend these without making > generator changes. Perhaps have some form of central "registry" to > hold these classes so that they can be globally looked up but > also replaced/extended if desired. > > The other suggestions are all very good - especially removing village. > > Thanks > > Joe >
