It has bugged me for some time that the om and peer objects are in
different packages. There are places where it would make much more
sense to make an attribute or method package friendly or protected and
we cannot do so because these closely related classes are in separate
packages largely for source file organization. I am pretty sure no one
would agree that is a good way to use packages, so is there some other
benefit that anyone sees to this arrangement?
In the latest torque version, I have moved the BaseXXX classes to a
.base subpackage again as a way to keep them out of the way, when I did
this I put the BaseXXX and BaseXXXPeer classes all in the same package.
But the movement into the .base package still does not allow the use of
package friendly methods. Because the non Base classes are not in the
package.
I would really like all these files to be in the same package as I think
it is the most correct. However for a large database schema it will
lead to a lot of classes in one package. Any disagreements to using one
package?
The other thing I would like some comment on is the reservations people
would have to violating the file hierarchy/package structure symmetry
that is generally followed in java src trees. If we put all the om/peer
objects in one package but still present the source files as
om/
om/peer
om/base
om/base/peer
would this cause any problems or criticism?
John McNally
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
