Hi Joachim
Joa...@tp... wrote:
> Hy,
>
> I'm once again digging deeper into OJB, so I'll be back for some more
> questions, please be patient. Some of them are very small and may sound
> like nit-picking, but i'm just interested.
I like nit-picking discussions ;-)
>
> 1.) most parameters that are ClassDescription objects are named "mif". Why?
historical reasons: once upon a time ClassDescriptors had been called
"MetaInfos", abbreviated to "mif". Now I'm using "cld" to name a
ClassDescriptor variable or parameter.
>
> 2.) some classes use an "m_" prefix for member variables, others don't. Is
> there an "official" way? Personally I'd vote against them.
Also historical reasons. The first OJB prototype was build for workshop
with Java programmers with a C++ background. The "m_" made them feel at
home... ;-)
Of course it would be much better to have some kind of "coding
conventions".
But who is going to set them up?
And once we have such a set of rules: who is going to apply them to the
existing 370 OJB classes ?
>
> 3.) often there are constructs like "Identity oid = new Identity(obj);",
> where oid is never used. IDEA marks them with a warning, so I usually
> remove the variable (I can't remove the calls to new Identity(), 'though).
The call "new Identity(obj);" is needed to force computation of primary
key attributes. This is needed to avoid problems with Object References
in OJB client/server mode
> I think a better solution would be to move the logic away from the
> constructor and move it into a factory/getter-method (this would have the
> advantage that in the case of a VirtualProxy you could return the same
> Identity object). A "Identity.getIdentity(obj);" without assignment feels
> better to me, than a "new Identity(obj);" all alone.
You are right. We had some discussion on this issue an decided to use a
IdentityFactory backed by a cache to minimize overhead for contruction
of Identity object.
Florian Bruckner started to work on this, but I don't know how far he got.
Florian: have you finished this or did any unforeseen problems occur?
>
> 4.) Sometimes while browsing I find files with broken JavaDoc (mostly "
> @something a parameter" instead of "@param something a parameter" and wrong
> parameter names). IDEA shows them as errors (it has an option to show them
> as warnings, but I prefer keeping clean javadoc). Is it a OK when I commit
> files where I only change the javadoc (I can't complete missing JavaDoc
> most of the times, 'cause I don't know enough, yet).
Sure!
The OJB code has been "treated" by several IDEs, Editors and Sourcecode
manipulation tools. That's why it's full of JavaDaoc errors.
Of course it is a good idea to clean things up. Thanks for all your
efforts in this direction.
>
> 5.) Same is true for unused imports/functions/member variables. For example
> getCollectionFromQuery(Class,Query) in PersistenceBrokerImpl is never used.
>
Yes, that's true too. I know IDEA has a cool feature to cleanup al
import statements accross a complete project. That's great. But:
the IDEA cleanup mechanism destroys
the preprocessor statements for importing JDK 1.2 proxy replacement.
Thus you have to be very careful in applying it!
> 6.) is it correct that the new build process doesn't use the build
> directory anymore?
Yes, we are moving to MAVEN driven build mechanism. Maven wants to call
this directory "target".
if this is true, could we remove the build directory
> from cvs?
sure! "Build", "dist" and "target" directory are definitely not needed
in CVS!
cu,
Thomas
>
> regards & thanks in advance
> Joachim Sauer
>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
>
>
>
|
