Bug 2722

Summary:	Polymorphic behavior of <<= will affect typecode subsetting
Product:	TAO	Reporter:	Jeff Parsons <j.parsons>
Component:	ORB	Assignee:	DOC Center Support List (internal) <tao-support>
Status:	ASSIGNED ---
Severity:	minor	CC:	jwillemsen
Priority:	P4
Version:	1.5.3
Hardware:	All
OS:	All

Description Jeff Parsons 2006-11-20 14:05:57 CST

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.

Comment 1 Jeff Parsons 2006-11-20 14:08:45 CST

Johnny, we can reverse things if you want - assign it to you and add me to the 
CC list.

Comment 2 Jeff Parsons 2006-11-20 14:09:19 CST

accepted for now

Comment 3 Johnny Willemsen 2006-11-21 01:35:24 CST

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?

Comment 4 Jeff Parsons 2006-11-21 09:27:53 CST

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.

Comment 5 Johnny Willemsen 2006-11-23 09:07:00 CST

See the point, Policy is a regular interface, then we have to think about
somethin g special

Comment 6 Johnny Willemsen 2006-11-23 09:13:50 CST

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.

Comment 7 Jeff Parsons 2006-11-23 10:53:21 CST

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.