incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Kühne (JIRA) <j...@apache.org>
Subject [jira] Updated: (YOKO-294) clean up ORB class hierarchy and remove package org.apache.yoko.orb.OBCORBA
Date Mon, 19 Feb 2007 20:25:05 GMT

     [ https://issues.apache.org/jira/browse/YOKO-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Lars Kühne updated YOKO-294:
----------------------------

    Description: 
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.

This class hierarchy seems to have something to do with backward compatibility issues in the
code before it was donated to Apache. To make the code simpler, the implementation code should
be moved from ORB_impl to ORB, then we can 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).

  was:
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.

This class hierarchy seems to have something to do with backward compatibility issues in the
code before it was donated to Apache. To make the code simpler, the implementation code should
be moved from ORB_impl to ORB, then we can 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).


> clean up ORB class hierarchy and remove package org.apache.yoko.orb.OBCORBA
> ---------------------------------------------------------------------------
>
>                 Key: YOKO-294
>                 URL: https://issues.apache.org/jira/browse/YOKO-294
>             Project: Yoko - CORBA Server
>          Issue Type: Improvement
>          Components: orb core
>            Reporter: Lars Kühne
>         Assigned To: Lars Kühne
>
> 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.
> This class hierarchy seems to have something to do with backward compatibility issues
in the code before it was donated to Apache. To make the code simpler, the implementation
code should be moved from ORB_impl to ORB, then we can 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).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message