db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joe Carter" <joe.car...@excite.com>
Subject Re: Torque 4.0 plan
Date Thu, 30 Nov 2006 23:14:00 GMT
Personally I'd just have the singleton and ditch the static wrapper
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
of the back-end should that be available.



On 30/11/06, Thomas Fischer <fischer@seitenbau.net> 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
> joe.carter@gmail.com 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
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message