I have been working for about three days trying to come up with an
abstract superclass to work with a couple of the classes the torque is
generating that have common properties in how they interact with the
database. It has been a real pain because of how many methods in BasePeer
are declared static and because of how java manages static methods.
Specifically:
a. Static methods are hidden, not overridden. For the code:
GeneratedClass gGlass = new GeneratedClass();
gClass.doSelect(criteria);
((BasePeer)gClass).doSelect(criteria);
The first doSelect call will succeed because it will call into the
method generated by torque which populates the select fields before
sending it on. The second call to doSelect will just run the method in
BasePeer and will fail.
The is not what would happen if doSelect was not declared static, I
would get the correct version of the method either way then.
I am writing a class that sits in between the two and since the method
is static I am only able to call into BasePeer unless I use reflection
to get an actual instance of the subclass.
b. Abstract methods may not have static implementations. This code will not
compile:
public abstract class AbstractSuperclass {
public abstract void addSelectColumns(Criteria criteria);
}
Where the AbstractSuperclass is the superclass of a generated peer. If
I could do something like this then I could do some workarounds to get
the code to work, but I can't do this either.
All in all, having so much be static in BasePeer really makes doing this
sort of work almost impossible without heavy use of reflection which has
an undesirable performance penalty.
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?
Will Holcomb
--
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>