Bug 2072 - generation of convenience code for valuetypes/eventtypes
Summary: generation of convenience code for valuetypes/eventtypes
Status: ASSIGNED
Alias: None
Product: TAO
Classification: Unclassified
Component: IDL Compiler (show other bugs)
Version: 1.4.4
Hardware: All All
: P5 enhancement
Assignee: DOC Center Support List (internal)
URL:
Depends on:
Blocks:
 
Reported: 2005-03-23 10:50 CST by Jeff Parsons
Modified: 2018-01-15 11:21 CST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Parsons 2005-03-23 10:50:01 CST
1. In cases where the generated C++ classes for the valuetype and its 
associated factory must be subclassed by the applications developer (valuetype 
has an operation, explicit factory, or private member declaration), we could 
generate a stencil for the impl classes similarly to what we can do now for 
interfaces. This generation would be triggered by a command line option, and 
would go into a pair of separate files - fooV.h and fooV.cpp from foo.idl, for 
example. The code for private member accessors and mutators could be 
completely generated - factories and operations would require the developer to 
supply the business logic.

2. In cases other than the above, where subclassing is not required, we could 
generate code to register the valuetype factory with the ORB, so the developer 
would not have to add it to application code. There are a couple of related 
issues with this:

 - does the factory need to be registered with the client ORB, server ORB, or  
both?

 - depending on the answer to the above, where is/are the best place(s) to do 
this generation? One choice would be in the constructor(s) of an interface 
that uses the valuetype in an operation signature or an attribute, but this 
would be hard to implement if the valuetype were deeply nested in some complex 
type used by the interface. Another choice would be to generate a separate 
file, thus ensuring that the registration call would be made only once 
(although I don't believe it's an error to try to register a factory multiple 
times, it would be inefficient). I'd welcome suggestions from anyone who 
stumbles across this entry. Note that this registration code is already 
generated by the CIDL compiler for components that have event sink ports, in 
the constructor of the generated _svnt class. This is relatively easy, since 
the use case is very specific.
Comment 1 Jeff Parsons 2005-03-31 12:55:07 CST
accepted