Hello Lars,
I'm not aware of any reason why this was specifically implemented this way.
The
comment seems to suggest that this may have had something to do with older
versions of the donated code, but since that isn't so much of an issue in
Yokos
case (since there are no older versions to deal with), it probably should be
cleaned
up to make things a bit cleaner and easier to understand.
The only real difference I see between the two is that the ORB is declared
final where
as the ORB_impl is not. Again, this probably has to do with what the
comment
describes, if the class is there for backwards compatibility purposes, then
they
probably wanted to prevent it from being used extensively and extended.
Cheers,
Darren
On 2/18/07, Lars Kühne <[EMAIL PROTECTED]> wrote:
Hi,
I'm currently looking for opportunities to make the code of the core orb
easier to understand.
One of the things I found confusing is this:
package org.apache.yoko.orb.CORBA;
// This class must be public
public final class ORB extends org.apache.yoko.orb.OBCORBA.ORB_impl {
//
// This class exists solely for backward-compatibility and
ease-of-use
//
}
The same class hierarchy is used for ORBSingleton.
Why is that necessary? Can't we move the implementation code from
ORB_impl to ORB and then remove ORB_impl (dito for ORBSingleton)?
If both _impl classes can be removed, that would leave us with only
PollableSet_impl in the OBCORBA package. PollableSet_impl is only used
in the OBMessaging package, and could be moved there (and maybe also
become package private).
Thoughts?
Lars
