From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7eb197ff5e1a70c8 X-Google-Attributes: gid103376,public From: brad.balfour@ois.com (Brad Balfour) Subject: Re: Ada -> IDL (this is not a typo!) Date: 1998/12/03 Message-ID: <7472hm$5cc$1@supernews.com>#1/1 X-Deja-AN: 418389124 References: <366543C6.3E232C33@lmco.com> X-Complaints-To: newsabuse@supernews.com X-Trace: 912723318 VRL06/YYI57C2CF20C usenet57.supernews.com Organization: Objective Interface Newsgroups: comp.lang.ada Date: 1998-12-03T00:00:00+00:00 List-Id: In article <366543C6.3E232C33@lmco.com>, "Marc A. Criley" wrote: >While the CORBA/Ada vendors provide IDL compilers to >generate Ada 95 from the IDL, is there a "decompiler" >that does the reverse? >Given a set of type declarations in a package (and the >packages that are depended upon) that are used for >external interfacing, is there a tool out there >that will generate corresponding IDL? No, not to my knowledge. It is certainly technically feasible, but I'm not sure that the result is what you'd like. Let me explain: [A] Feasible: It is quite possible to create a mapping from an Ada package specification to the corresponding IDL declarations. However, the OMG (and its Ada revision task force) have not done so. Most Ada constructs mapping from IDL to Ada is trivially reversable from Ada to IDL. There are certain Ada constructs that don't have an obvious mapping to IDL (e.g., access types or private types). Certain patterns in Ada would need to be recognized and mapped onto IDL constructs. However, such a mapping is technically possible. In fact, Objective Interface's ORBexpress idl2ada tool has been architected to not only emit Ada from IDL, but to be able to read that Ada back in. Among several possible future enhancements to the tool is a reverse mapping as you have proposed. However, that feature is not present in the current product. [B] Desirable: Given that it is possible, you might wonder why no one has done it. Certainly, the proposal comes up on a regular basis. Why have no CORBA developers come pounding on the ORB vendors doors demanding this feature? Let me describe one major area where an Ada package and an IDL interface differ: An Ada package specification exports subprograms. The semantics of these are those of local procedure/function calls within a process. An IDL interface is a (potentially) distributed interface. Calls to the operations in an IDL interface may result in a remote invocation of the operation's implementation (in another process, possibly on another machine). Clearly, while the function behavior of these two operations may be identical, the performance and other kinds of semantics may not. As an example, it is common to design an Ada package to export a "list" type with an associated iterator. A programmer then calls on the package to set up the list/iterator and to retrieve the first value. Then, in a loop, the programmer calls "get_next" repeatedly to get & process each value. This is a classic design and a common package interface. It is also horribly designed IDL. If one were to create a (potentially remote) IDL interface with this iterator model, the programmer would find that the performance is unacceptable. It is very expensive (relatively speaking) to call the remote implementation in order to return a single "element" of the "list". A much more efficient remote interface will "batch up" the results and return a series (i.e., a sequence) of these "list elements" to the client in a single remote call. The client then iterates through them locally. [C] The Conclusion: It is often desirable/necessary to redesign some/many/all of the interfaces to account for the potentially distributed nature of IDL. While this doesn't eliminate the desire or need for a tool like Marc describes, it does explain why the process isn't as automatable as one might think. All that having been said, however, should Marc or anyone else really want such a tool, we'd never turn down money to build one for you :-) I hope that this explanation answers your questions. Thanks, Brad -- Brad Balfour Director of Technology Services Objective Interface Brad.Balfour@ois.com 703/295-6533 (voice) 703/295-6501 (fax)