Hi,
Thomas Dudziak wrote:
I did not want to advertise the IFoo style, I only gave it as an example.
I don't like the IFoo/FooIF too. As suggested in pervious posts the "normal" class name without Suffix/Prefix seems to me the simplest naming pattern for interfaces.
One benefit of this style however is that it leaves names
like QueryFactory open which can be used by the convenience classes that provide static acces, e.g. QueryFactory and PersistenceBrokerFactory.
I think in these specific cases we can allow exceptions and for OJB1.x this will happen only once (if any ;-)) after the complete refactoring.
For other naming schemes we would have to think about a naming pattern for them. Though I wouldn't mind if we get rid of them altogether. If need be, we could put the static access to the default PB into the OJB class
For 1.x I suggest to completely separate the PB-api from the kernel (PB-api == PB/PBF). So the PB-api will be an API like ODMG, JDO,... a kind of top-level api.
I will post a separate thread with detailed information. After this separation static access to PB instances is no longer needed/possible.
The main issue that I see is that we need a naming standard in this area. If there is a consensus about this, then we could vote the standard to use.
+1 for naming standard
in advance
+1 for using plain class names for interfaces
+1 for FooAbstractImpl, FooDefaultImpl or FooImpl if this is the only implementation class shipped with OJB.
+1 for FooFactory for factory classes
And to Martin's point, I tend to agree that the scope of changes inside HEAD merits a '2.0' moniker. That would free up the possibility of introducing releases from the current 1.0.X line that contain more then just bug-fixes, and the release number could more accuretly reflect that.
I don't know, most of the changes are internal (IoC, most services are configurable etc.), there are only a few changes that are visible and relevant for normal usage, most notably probably the introduction of the OJB class and the PersistenceConfiguration.
I think we should make a clean sweep for OJB 1.x and rethink/check classes and methods, adding new features, move/merge methods and classes (package name structure?? useful?), ...
and after all these operations we can make a decision about the release version number 1.1, 1.5, 2.0 (maybe we have to name it OJB 5.0, because it's sooo outstanding ;-))
regards, Armin
Tom
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
