templated ObjectAdapter::add() and createProxy()

Unknown

Other than compiler support for templated member functions, is there a reason the obligatory uncheckedCast() can't be removed by adding new templated member functions that return the derived proxy? This would leave:

SomeClassPtr servant = new SomeClassI;
SomeClassPrx proxy = adapter->addWithUUID(servant);

Using type deduction the entire call could be typesafe and more concise. Perhaps these functions would be removed by the precompiler for older compilers like VS6.

marc

The object adapter interface code generated from Slice (slice/Ice/ObjectAdapter.ice), and Slice does not have any concept of template functions. So we would either have to not use generated code, or add a template concept to Slice.

The advantage of using generated code is consistency: All Ice versions for all language mappings offer exactly the same object adapter interface, with the same language mapping as for any other interface. Adding template functions to Slice is not an option either, because such template functions wouldn't map to other languages, such as Java.

System

I see your point. What if the template member function mechanism was not represented directly, instead it would be C++'s mapping of a specific slice notation. Perhaps a slice line similar to:

(Object isA T)* createProxy((Object isA T), Identity);

could map to C++:

template <class PtrType>
::IceInternal::ProxyHandle<typename PtrType::ProxyType> 
      createProxy(PtrType, Identity);

While in other languages without templates/generics the mapping would just serve to assert that you can safely downcast to the real type (T) of Object with an uncheckedCast().

Thus, in C++ the whole createProxy() usage could carry out without any casts, and in other languages, it would not change anything syntactically, just give extra semantic information.

Even in the unlikely case this is feasible, I know this would require significant changes. I'm really just trying to understand the whole system and understand design rationale.

marc

While something like what you suggest might work (but only for modern C++ compilers), I believe that it would add way too much complexity for too little benefit. Therefore it is unlikely that we will add this.