Please report new issues athttps://github.com/DOCGroup
After discussions with Frank Pilhofer about spec issues, it appears that Any insertion operators are supposed to behave polymorphically, for IDL types that support inheritance (interfaces, valuetypes, eventtypes, etc.). Extraction from an Any first checks the typecode for a match between the content and the operator's rhs. Also, when the Any is sent over the wire, it is encoded and decoded by traversing the typecode it contains. All this implies that types that support inheritance must be inserted using the most derived typecode, regardless of the type of the insertion operator's rhs. The obvious way to do this is with a virtual method, called let's say '_tao_type()', generated by the IDL compiler for each declaration of an interface or valuetype. However, there is a problem with this approach. Such a method breaks the decoupling in generated code between the type and its associated typecode, meaning that the AnyTypeCode library must always be linked to generated code containing interface or valuetype declarations. Valuetypes, being not so common as yet, aren't that much of a problem, but interfaces are another story, since almost every IDL file will contain one or more. If the AnyTypeCode library is not to be simply merged back into the core, resulting in a large footprint increase, another approach will have to be found to polymorphically retrieve the typecode from the rhs of an Any insertion operator.
Johnny, we can reverse things if you want - assign it to you and add me to the CC list.
accepted for now
The problematic area is the TAO library itself (so the files in TAO/tao). I did have a quick scan, but doesn't we only have local interfaces in that directory? If yes, can't we disable the any insertion for these local interfaces with -Sal? We did this in the past by default but it seems we with the introduction of this option we do generate the any insertion again by default. When any insertion is suppressed we then can zap the _tao_type method in the generation?
The main problem I think are the CORBA policy interfaces. They are local, yet must be inserted into an Any. That's the reason the generation of Any operators for local interfaces was reinstated.
See the point, Policy is a regular interface, then we have to think about somethin g special
Jeff, for Policy.pidl we don't do an automatic regeneration, see PolicyC.cpp, there I already use the AnyTypeCode adapter for retrieving some typecodes. Can't we do the same for policy also? Add tao_type to policy and add a method to the AnyTypeCodeAdapter to get the typecode when requested. For valuetypes I think we should add tao_type soon, that will probably not be much work, probably only removing -GA for some pidl files (like ExceptionHolder) For local interfaces I don't think we need it for the interfaces in the core libs itself, we could suppress them there and the users can decide to enable them for their own local interfaces.
Yes,s using the adapters is the right way to go I think - I was just worried that there would be too many occurrences, but it seems there isn't. I already have _tao_type() for valuetypes in my laptop workspace. As for local interfaces, there may be other issues besides Policy, if Policy isn't a local interface. I have definitely suppressed generation of Any operators for local interfaces before and had to put it back because of some issue, maybe it was a different one, I'll have to try to look it up sometime.