ITCR — Skeleton class as consistent template parameter for CORBA::servant_traits

Instead of the IDL interface class, the skeleton class should be used as template parameter for CORBA::servant_traits<>.

Rationale:

1. The servant which the traits describe is realized by an instance of a class derived from the skeleton class which in turn (directly or indireclty) inherits PortableServer::Servant but not necessarily the interface class.

PortableServant::Server < ... < CORBA::servant_traits<A_skel>::base_type < A_impl

instead of

PortableServant::Server < ... < CORBA::servant_traits<A>::base_type < A_impl

(A, A_skel and A_impl are arbitrary names denoting the interface, the skeleton and the implementation class, resp.).

2. In chapter 6.26.4 "Servant argument passing", we have CORBA::servant_traits<PortableServer::Servant>; this takes (the very basic) servant class as template parameter.

CORBA::servant_traits<PortableServer::Servant>::ref_type < CORBA::servant_traits<A_skel>::ref_type

instead of

CORBA::servant_traits<PortableServer::Servant>::ref_type < CORBA::servant_traits<A>::ref_type

3. In chapter 6.26.3 "Servant references" CORBA::make_reference<...> takes the implementation class as argument to create a CORBA::servant_traits<...>::ref_type. This would be more consistent with CORBA::make_reference<...> taking an interface class as parameter to create IDL::traits<...>::ref_type.

CORBA::make_reference<A_impl> -> CORBA::servant_traits<A_skel>::ref_type

like

CORBA::make_reference<A> -> IDL::traits<A>::ref_type

instead of

CORBA::make_reference<A_impl> -> CORBA::servant_traits<A>::ref_type

4. CORBA::servant_traits<...>::base_type is used as base class for implementation classes in §§ 6.26.6 and 6.26.7. Having CORBA::servant_traits<A_impl>::base_type instead of CORBA::servant_traits<A>::base_type is more consistent with the use of IDL::traits<LocalIF>::base_type denoting CORBA::LocalObject or something derived from CORBA::LocalObject.

CORBA::servant_traits<A_skel>::base_type < A_impl

like

IDL::traits<LocalIF>::base_type < MyLocalIf

instead of

CORBA::servant_traits<A>::base_type < A_impl

This affects all uses of servant_traits in §§ 6.26.3, 6.26.5, 6.26.6, 6.26.7.

The disadvantage to be considered is that the naming of the skeleton class is not standardized, so implementation classes to be provided by a programmer using an IDL to C++11 framework package cannot longer inherit a well-specified base class like CORBA::servant_traits<A>::base_type. Instead something like CORBA::servant_traits<skeleton<A>>:base_type would be required where skeleton<...> is a framework-specific template.

Keep referring to A instead of A_skel

One of the basic rules we defined for IDL2Cpp11 is that we don't want the user to remember all kind of rules to translate between the IDL name and some Cpp11 type. At the moment a IDL type is translated to multiple C++ types we are using the IDL traits. The concept of a skeleton exists in IDL2Cpp11 but the exact class of the skeleton is accessed by the user using the CORBA::servant_traits. The proposed change will complicate the life for the user without any benefit.